I've noticed Arkshine is nub at Git so I'm gonna give some suggestions.
Let's say you are going to work on function MakeMyBunnyHappy. The changes involve various files and it will take some time to finish that feature.
Before you start doing your changes, update your local copy with
Code:
git pull
The next thing you should do, and this is what makes it almost impossible to break things, is branching off the master branch:
Code:
git branch makemybunnyhappy
Now you are working on your own local branch - right now it's the exact same as the master branch.
Do your work here, add stuff, modify other files, and make your bunny happy. Remember to commit groups of changes that belong to the same logical group (e.g. 'including makemybunnyhappy signature in the list of known functions', or 'make IsBunnySad automatically call MakeMyBunnyHappy if bunny is sad ').
When you're finally done with the changes related to MakeMyBunnyHappy, make sure you've committed your local changes.
Now it's time to merge your changes back into master. First, update your local copy with
Code:
git pull
then start the merge with
Code:
git merge master
(Hint: you can always check the master branch before starting the merge, and fix any conflicts you find)
If your changes don't conflict with the changes in the master branch, you're done, you can just push your changes. In the case git-merge finds conflicts, it will include markers in the files telling where there are conflicts. Use
Code:
git diff
to see what are the conflicts.
Remember, fixing merge conflicts isn't just a matter of merging code changes, you have to test, see if it does what it's supposed to do, etc.
After you fix the conflicts,
Code:
git commit -a
will commit the result of the merge, and you can push your changes to the remote repository (in this case, GitHub).
That's it, once you get the hang of branching, you see how easy it is to develop concurrently without conflicting with other peoples' changes.
EDIT: Attachment removed. This update is now integrated to 1.8.3.
Almost all virtual functions related to player/weapon has been added for each mods.
Please note the module title and version are temporary changed.
v1.4 is the last version (2013, 14 April).
Fixed from original :
Vector as return is now fixed. All functions returning a vector won't crash anymore. (Ham_GetGunPosition, Ham_Center, etc.. )
Some offsets were misaligned for CS and DoD.
SendWeaponAnim for CS is now fixed and renamed to Ham_CS_Weapon_SendWeaponAnim.
Fixed TakeHealth call (one param wrongly converted, thanks Nextra)
Fixed hamsandwich vtable patching on Linux for newer GCC binaries (by DS)
Added Ham_TFC_Killed
Updated CS/DoD/TFC/Op4 offsets
Added support for Mac OSX (but binary will not be provided for now, sorry)
I think Seta is thinking about keeping the publicly accessible version stable as opposed to a "public 'in-progress' version". If I go pull it at any time, it should be a stable or semi-stable version that someone would be able to modify from (as opposed to modifying a non-working version meaning my new version is also non-working).
I think Seta is thinking about keeping the publicly accessible version stable as opposed to a "public 'in-progress' version". If I go pull it at any time, it should be a stable or semi-stable version that someone would be able to modify from (as opposed to modifying a non-working version meaning my new version is also non-working).
What he said could mean that for other cases but for this one I think its just really because of concurrency or cleanliness of the operation. I mean, that is a more advanced use of branching and I think he is talking more at a basic level.
I think Seta is thinking about keeping the publicly accessible version stable as opposed to a "public 'in-progress' version". If I go pull it at any time, it should be a stable or semi-stable version that someone would be able to modify from (as opposed to modifying a non-working version meaning my new version is also non-working).
Exactly, that's another good thing about working in branches. I use nvie's git-flow model with the gitflow extension, it makes it extremely easy to do the branching:
Code:
git flow feature start myShinyFeature
# work on feature, commit. feature is done
git flow feature finish myShinyFeature