git pull vs git rebase

[Tim Moore <timoore@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm glad to see everyone git-ing away. The tip of the master branch is looking a bit
convoluted with merges, so I thought I might remind you of the difference between
"git pull" and "git rebase". Your tree has to be up-to-date with respect to the remote
master branch before you push, so it's natural to "git pull" after you've made local
commits in preparation for a push. Unfortunately this often results in a merge conflict,
especially with the ChangeLog files. So you resolve that, but then your pushed commits
include the merge commits, which confuses the history.

Instead, you can rebase your local commits to the tip of the master tree before doing
the push. "git fetch origin" updates your local copy of the remote branches on sourceware;
then "git rebase origin" will "replay" your local, new commits on top of the current
remote branch. If there are merge conflicts in this process you resolve them and continue
the "playback," but the resolution doesn't appear as a merge commit in the history. Now,
when you push your new work, it's all clean; no merges in sight.

So, read the man page on "git-rebase" and give it a try.

Tim

- --
Red Hat France SARL, 171 Avenue Georges Clemenceau
92024 Nanterre Cedex, France.
Siret n° 421 199 464 00056
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHI3npeDhWHdXrDRURArAkAJ0U8/1PlKuwGbFCUTtPloAhzhjBAQCeL0Q9
2+47vugUbDmr7a7d2V6EHOc=
=vCsu
-----END PGP SIGNATURE-----