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

[Stephen Haberman]

> git rebasing, or any such repo trickery scares me. Anyone doing this,  
> or equivalent admin magic in their repo?

Linus actually addresses your concerns in that post [1], to quote him:

    You must never EVER destroy other peoples history.

And:

   Minor clarification to the rule: once you've published your history
   in some public site, other people may be using it, and so now it's
   clearly not your _private_ history any more.

This is exactly how I've worked with git before.

Once code is published to the public git repo (with "git push"), the
"never, ever, ever, re-work" rule you note with SVN comes into play.
You /can/ change the public git repo with rebase, just as you /can/
rewrite SVN repo history with svnadmin commands, but neither is
recommended, and there are settings to disallow it.

(Specifically, in git it's called disabling rewinds, where rewinds
== the undoing of commits.)

The only place rebase is recommended, AFAIK, by myself and also Linus
in [1], is on your own local commits that no one has seen yet and that you
are just cleaning up before publishing.

This is all because git is distributed--you can make commits, "git
commit", but they are only local. You could have 2-3, 10-20, whatever
commits locally and not publish them until you "git push". Since no one
has seen these commits yet, its perfectly acceptable to clean them up
(reorder them for clarity, remove some that ended up being mistakes,
etc.) via rebasing.

However, once you publish/share your work, the commits should become
immutable, and you don't rebase them anymore. And, again, this can be
enforced by the public git repo to avoid people slipping up.

Most corporate teams probably don't care about rebase because they
either do not do code reviews at all (most likely) or else do code
reviews against branches before release and not per-commit. The nature
of Linux development is that they review all code on a per-commit basis
via email lists. This makes it very, very important for each commit to
be as logically coherent as possible. Which it probably was not when the
developer first wrote it. So, Linus/et. al really encourage their developers
that, before publishing their commits to them for review, they step back
and rebase them to make each individual commit about one and only one
change. This makes per-commit review on mailing lists much easier.

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).

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

- Stephen

1: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html