Advocacy vs. git

[Theodore Tso]

On Fri, Apr 24, 2009 at 01:10:47PM -0500, Kevin Bullock wrote:
>
> It's my contention that rebase is like goto: useful for the few cases  
> where you need the raw power, dangerous when used for common cases. But I 
> could be wrong. I've explored the rebase extension a bit, but haven't 
> found a use for it yet.
>
> Do others use the rebase extension in daily work? What's the advantage?

How useful you find rebase really depends on where you find yourself
on the continuum between:

   *) What should be stored in the source code repository is the
      "perfect patch" or "perfect patchset" which implements a
      particular feature or bug fix.  Typos, bug fixes, merges to
      track changes in the upstream should be omitted since they dirty
      up the repository and make it harder to understand six months
      later --- especially if there is a desire to cherry-pick the
      patch for backports.

   *) Everything that should be stored in the source code repository,
      development warts and all, and it should be stored forever,
      since it reflects the development history.

The end point on the latter can be taken to an even further extreme,
and in some IDE's, you could imagine systems where you are forced to
do a commit before you are allowed to compile an executable.  That's
silly, of course, but it perhaps illustrates the point of why some
people tend to tend find themselves closer to the "perfect patch" end
of the continuum than the "preserve all history".

Also note that the preference does not have to be project-wide,
although within a *team* it there needs to be a shared understanding
of how things work.  A single person or a single team can decide that
for their subsystem, they want to submit and maintain "perfect
patches" as much as possible before they are submitted upstream.  If
that is true, then the tools that allow them to do this, whether it is
Mercurial Queues, or rebase, or (in the git world) guilt, stgit, and
git-rebase are all tools that can be used towards creating "the
perfect patch". or "perfect patch series".

Depending on what you are trying to do of course, there may be other
tools that may be better than rebase.  Mercurial Queues effectively
can work just like rebase, by the way, just perhaps not as efficiently
if all you are trying to do is the rebase operation.  The main thing
that rebase allows you to do is to produce a "linear history", which
some people find easier to understand.  Personally, I think the
desireability of a linear history is overrated, but eliminating merge
points when they aren't necessary is a good thing.

Of course, if you have a development process which emphasizes frequent
pushes to mainline, this may be much less of an issue, but if you have
some feature set where a you want to do a large amount of work before
pushing to mainline, rebase may be exactly the ticket.  Of course, you
may find that in those environments you want more than rebase, at
which point something like Mercurial Queues may be more useful.

Two final points that I think are worth making.  First, "git rebase
-i" is nicer than MQ simply because you don't have to do much in the
way of setup.  If you have done a series of commits, and then decide
that, before you've pushed them out, that you want to squash two
commits together, and perhaps edit the commit log for a third, you can
use "git rebase -i" for quickly and easily.  With MQ you have to spend
a bit more time setting up the mq.  The functionality is equivalent,
but it's just perhaps less convient for ad hoc use.

Secondly, I disagree with your strawman that "git rebase" gives it an
inherent advantage of Mercurial.  The reality is that Mercurial has
most of the functionality of rebase; it may not be as convenient to
use, and it might not be as fast from a performance point of view, and
you may have to explicitly enable it since Mercurial's author thinks
that any kind of history modification after it has been committed into
the local repository is should be avoided.

And that's what this is really all about; there is a philosophical
divide around history modifications, and when this should be
justified, and it should be avoided.  Matt Mackall believes very
strongly that most (all?) of the time mutating the history is Evil.
So these features are disabled by default, and relegated to
extensions, even if the extensions are enabled by default.  But it's
not like the features don't exist for Mercurial!

They might be more _painful_ to use, sure.  So for me, if we must talk
about "killer features", the one which is why I prefer to use git is
"git commit --amend".  I will very often create a commit, and then
about 30 seconds later, realize that I had typo'ed a comment, or the
feature could be made even better if I made some further changes.  So
at that point, I'll quickly edit the source files, make the further
enhancements, and then use "git commit --amend foo.c".  I do this
***far*** more often than I use rebase.

Could I do the exact same thing in Mercurial?  Sure.  I can save the
commit message via "hg log" or "hg export", then do a "hg rollback",
edit the files, then do a "hg commit" and pull in the original commit
message and update it if necessary --- but "git commit --amend foo.c"
is *easier*.

When I used Mercurial, fine-tuning a just-committed changeset was
enough of a pain in the *ss that most of the time I wouldn't bother.
With git, it's easier, so I create higher quality commits.  Maybe it
means I'm a lousy programmer and I should stop and wait 30 seconds,
thinking very hard, before creating the changeset --- because
changesets, once created, are **forever** and besides, the discpline
would be good for me.  Perhaps.  For me, it breaks the "flow" of my
work, and I don't believe in the bondage and discpline school of
development in any case.  These are all very personal issues of
preference.

But "fundamental killer-feature"?  That's not very pursuasive,
fundamentally because Mercurial has the functionality.  Maybe it's
second-class functionality, since the Mercurial core developers thinks
that any history mutation is Eeeeeevill.   But it *is* there.

Regards,

						- Ted