> > Instead of pulling, do 'git pull --rebase' or 'git fetch origin' followed by > 'git rebase origin/master'. This causes the following to happen locally: > D' > | > D C C > | | | > B B B B > | | | | > A A A A > > Begin Rewind Fast-forward Rebase > > When you rewind, you revert locally to the last commit that is shared by both > you and github. > > Then, the rebase process fast-forwards your tree to the latest changes from > github. > > Finally, the rebase concludes by applying change D on top of everything else > - which may involve merge conflicts - so the new change is D'. > > Now, if you re-push, and github's head is still at C, it can accept change D' > with *absolutely no risk* of merge conflict, and there is no need to undo > existing changes to do that. > > Does that make sense?
Rebase is indeed your friend when pulling from other repos while working on local patches. I would also like to add that personally I consider 'commit -a' evil (re. original post). It's a crutch for when one comes from another VCS and has never used Git, and needs to use it _now_, and quickly, and then leave Git. One should use 'git add' (or its alias: 'git stage'), and learn about the staging area. It's wonderful stuff. I would like to point again to the link that Jamie (IIRC) posted earlier: http://www.newartisans.com/2008/04/git-from-the-bottom-up.html It's got very simple stuff that can be re-done at the terminal as training material, and then Git as 'lists of commits' (re. Josh' drawings) suddenly becomes clear. -Tor ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
