Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Matthew D. Fuller writes:

 > > Revision 2 is identical to revision 1.1.1
 > 
 > Then why would you have to rebase it, instead of just sticking it on
 > the head of the branch as-is?

You don't *have* to rebase it.  In certain workflows, it is a sensible
choice.

 > You'd only need to rebase if there were already a 2.  But then 1.1.1
 > HAS important imformation that the putative '3' merge wouldn't; it
 > knows that it came from 1 rather than 2.

Sure, except for the "important" part.  For example, I have two
experimental workflows.  In one, every explicit save auto-commits to a
an autocommit branch, and I use rebase --interactive as a poor man's
substitute for Darcs interactive record.  In the other, autosaves get
autocommitted as well.  The second seems to be overkill :-), the first
is actually fairly useful, since in practice I often get interrupted
without a commit, then come back and make changes that confound the
changeset -- and then need to sort that out before the commit.  This
practice also ensures timely timestamps.

So what happens in the first workflow is that I've learned to
partition work with saves.  Oh, there's a typo! save-fix-save.  (AKA
the "$VCS rebase samba".)  I somehow doubt this workflow is for
everyone, but it works well for undisciplined amateurs (at least this
one!)  Then later all the typo fixes get filtered into a separate
branch for immediate application to the mainline.

It is true IMO that some merges should *not* be eliminated by
rebasing.  OTOH, I also simply don't see a need to preserve certain
aspects of history, such as in the above workflows.  Finally, non-
fastforward merges can increase the testing burden as opposed to
rebase, if you have an "every public commit must be tested"
discipline.  Of course in a special case of Óscar's point, you can
also have an "only mainline commits must be tested" discipline, in
which case merges decrease the testing burden.

So I don't really see an excuse for *Bazaar* being religious about
rebasing or preserving absolutely all history.  Given its mission of
flexibly supporting various workflows without external scripts and
other muss 'n' fuss, I think it should support rebasing (and in
general history manipulations) well.