Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Óscar Fuentes <ofv at wanadoo.es>
 > > Date: Thu, 04 Mar 2010 05:17:47 +0100
 > > 
 > > The first workflow that was recommended to the Emacs developers creates
 > > a merge for every change, even for the most trivial ones.

This is false; Bazaar recognizes fast forwards as well as any other
VCS.  It only creates a merge for a change in the case where
concurrent changes have actually happened in the project.[1]  The
"saner practice" substitutes a failed commit and update for the merge.

You pays your money and you takes your choice.  Many people prefer the
merge because it allows the developer to choose when to resolve
conflicts (ie at merge time), whereas the "saner practice" allows the
environment to force on you (or you can leave your familiar workflow
and go to a different one, which itself is an opportunity for error).

The rebase workflow has the same advantage.

 > IMO, advising those who didn't to switch to ``saner practices'' is a
 > better path than telling them to use "bzr rebase".  The result will be
 > the same, but with much less potential for confusion and errors.

Not obvious.  If you get a merge conflict (which can occur at update
time in the allegedly saner practice), there are opportunities for
error and confusion.  ISTM that the main advantage to this is that
it's a familiar workflow to those with CVS experience.

Personally, I prefer the rebase workflow because I'm in "careful mode"
when rebasing, and that's when I'll actually get a conflict.  On the
other hand, when I get a merge conflict at update time, my frustration
level rises, and I reach for a hammer, the bigger, the better.  I'm
not advocating rebase for others, but it's not implausible.

And with the exception of OpenSolaris (whose first commandment of VCS
is "thou shalt not leave merge turds" and therefore rebases with
abandon) all the Mercurial projects I know (about four others) use the
"merge all concurrent work" strategy.  It will be interesting to see
what strategy Python itself adopts.

Footnotes: 
[1]  Ie, those cases where Ben Finney and perhaps Stefan Monnier would
express a strong preference for merging.