Will re-basing support be added into Bazaar core ?

[Andrew Bennetts]

Russel Winder wrote:
> On Mon, 2009-04-20 at 12:14 +1000, Andrew Cowie wrote:
> > On Sat, 2009-04-18 at 13:16 +1200, Talden wrote: 
> > > Being in core it would
> > > be likely to be maintained and tested more aggressively
> > 
> > The core hackers mostly seem to advocate that rebasing is evil.
> 
> I have never understood why "Rebasing is Evil".  Surely it is just
> another tool in the armoury.  Used judiciously it is a valuable tool.
> Using it badly or inappropriately is the problem.
> 
> Personally I find it incredibly useful for long-term feature branches
> where it is important to track the mainline branch and have the ability
> to create a conflict free merge/patch.

There are two main drawbacks.  I'm pretty sure they've come up on the list
and in blogs fairly frequently, but in short:

One, rebasing is hostile to sharing your work in progress.  If you don't
want to share it yet, then that's not a big deal.  But if you have published
your branch where other people can branch or merge from it then rebasing is
generally a bad idea.

Second, it creates a history that you never actually had.  Depending on what
you expect from the history, that may or may not bother you.  If made a
commit with a commit message like “Now tests pass on platform X” and then
rebase it the commit message will still claim that, but you haven't actually
checked that the revision still does pass tests.  This can cause trouble for
some forms of archaeology, including bisect.  Or it may cause you no grief
at all and you fail too see what all the fuss is about... 

This is pretty well recognised in the git community, I think; e.g. here's a
recent post by Linus describing when he thinks rebase is and isn't okay in
kernel development:

    http://article.gmane.org/gmane.comp.video.dri.devel/34744

(Link found via http://lwn.net/Articles/328436/)

Also, it's worth realising that rebasing isn't the only solution to the
problem of “I want to present a nice history (in the form of a patch series
and/or mainline history) for my work.”  For example, although the
implementation is certainly still quite rough in parts, the loom plugin
quite successfully demonstrates an alternative approach to maintaining a
patch series that preserves the original history. 

That said, I'm sure all the core devs are relatively frequent users of “bzr
uncommit” for correcting typos and other trivial mistakes in recent
commits.  I know I am!  And a quick uncommit/recommit is in many ways the
same as a small rebase.

> > If they don't use it, I'm not sure it's a good idea to expect them to
> > work on it, or in turn to rely on such a feature.
> 
> But this doesn't stop people making proposals for patches to the plugin,
> and arguing for a move into core -- if such arguments can be made, I
> don't know whether they can, I just use the plugin.
> 
> Only if strong correct arguments for change are made will it be
> discoverable whether the core Bazaar development team are amenable to
> change of view or just quasi-religious zealots.  We all believe the
> latter to be false, but there hasn't been a test yet.

FWIW, even though I don't like rebase much, I'd still be happy to have it in
core.  I don't think we'd want to encourage people to use it regularly, and
I'd probably be tempted to have it as a hidden command.  But it is genuinely
useful sometimes, I don't think the extra code would be a great burden — and
certainly not enough of a burden to justify making life harder for people
that really want it.

> However, might it be that a strong initial path would be to contribute
> further tests to the plugin so that any perceived deficiencies in rebase
> support are fixed there?

An excellent test suite is always a good start.  This applies to more than
just getting code accepted into bzr core ;)

You could try “bzr --coverage /tmp/coverage-report selftest rebase” as a
relatively quick way to spot any obvious holes in the existing test suite.

-Andrew.