Re: [Omaha.pm] [odynug] Linus on git rebase

[Samuel Tesla <samuel.tesla@gmail.com>]

Everything Stephen said is spot on, however I'd want to make one
additional point...

On Sat, Jun 13, 2009 at 10:13 AM, Stephen
Haberman<stephen@exigencecorp.com> wrote:

> So, yeah, if you're not doing that, and don't care about a meticulously
> clean history, you probably don't care about git rebase and can ignore
> it. But Linus/et. al do, so they use it all the time (...on local stuff,
> before they publish).

The one time you /do/ care about rebase is when you're pulling remote
changes. If you have local commits on a branch, and you pull commits
in from the remote branch it will produce a merge commit. This
clutters up the commit history when you, in turn, push stuff back up.
The linux folks, especially, hate this. So, here's the command you
should get in the habit of using to pull changes from the remote
branch:

 $ git pull --rebase

If you're on a branch named master that tracks the remote branch
origin/master, it is the same as doing this:

 $ git fetch origin
 $ git rebase origin/master

What this will do is update the remote branches, and then go into
interactive rebase to rebase your local commits on top of the latest
remote commit. This makes it so that when you push stuff up, it's a
fast-forward instead of a merge.

> So, really, everything is the same as SVN, except you get a local
> sandbox to screw (rebase) around in.

Using the --rebase option to git-pull is especially important if you
are using git-svn to interface to an SVN repository, because SVN has a
linear revision history, and can get extremely confused by some of the
more non-linear histories that can arise if you don't carefully rebase
your local commits.

-- Samuel