Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

James Westby writes:

 > If however I rebase, then two new revisions will be created, one for
 > each that I had in my branch, bot of them untested. I can happily
 > test the end state, and so test the whole combination, as with merging,
 > but if I now checkout the parent of the tip revision then it may pass
 > the tests or not, regardless of whether it did when I committed it.

Very precise, not to mention accurate, statement.  Bravo!

Whether that matters or not is a workflow issue.  If you allow
untested revisions off the mainline (or published branch, or
whatever), but not on it, then a merge-oriented workflow is
appropriate.

OTOH, if you have a long-lived branch and consistently merge from
mainline into the branch, bisecting the branch means that you have to
worry about all the changes in the mainline; it's not just your code
that you're responsible for.  Eg, suppose my changes are revisions A
and C, while B is a merge from mainline.  If bisect fingers B as the
culprit, then my reaction (YMMV) is going to be "You broke my branch,
go fix your patches now!"  And "historically" that is correct, but I
don't think it's the most appropriate reaction (even though it's my
natural one!)

In a rebase branch, though, it's very likely that A' will break, and
my reaction is to see what I did wrong.  A deeper analysis may lead me
to say "You broke my branch!" anyway, but in the rebased setup I'm far
more likely to look for a "modular" fix.  If the whole project is
factored well, I suspect (without being able to point to relevant
experience, I admit) that that leads to a better end product.

 > However, rebase often comes with an effort to try and reduce the number
 > of merge revisions, in which case you are putting these untested 
 > revisions on to your mainline, rather than keeping them off to one side.

This is especially true of Mercurial, which encourages a working style
with multiple branches where you may fix a typo here, a typo there,
then push both one-offs to mainline, where you get a pattern of patch,
auto-trivial-merge, patch, auto-trivial-merge, lather, rinse, repeat ...
that is really ugly.

 > Of course some would argue that my last paragraph was utter nonsense in
 > a distributed world.

I'd argue they don't know what they're talking about.

Regards,
Steve