>
> 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
Received on 2010-06-09