Will re-basing support be added into Bazaar core ?

[Russel Winder]

Andrew,

On Mon, 2009-04-20 at 17:55 +1000, Andrew Bennetts wrote:
[ . . . ]
> 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.

This is undoubtedly true.  In the Groovy, Gant and Gradle projects we
have had (interminable :-) debate about how we can use Bazaar and Git
where the mainline must be a Subversion repository.  Rebase is both
essential and yet it is anathema.

I have been trying to get people just to have Bazaar branches in
Subversion repositories but Git rather than Bazaar has the zeitgeist in
the Grails, Groovy, Gradle, Ruby on Rails communities.  Sadly.

Gant proudly remains a "Use Subversion as a Bazaar branch repository"
project.

> 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... 

I guess the argument here is whether history is more important that the
ability to merge back with comprehension.

I agree that commit comments can be overtaken by events and become
entirely useless, but this is going to happen anyway as the code evolves
-- especially when code gets deleted completely.  I understand those who
want to ensure the history is valid as a record, for them rebase really
is anathema.  I am more concerned with merging changes back to mainline
with a trivial comprehension on what changes are lined up.  Rebase seems
to be the best tool in this situation exactly because it puts all the
"to merge" changes on top of a mirror of the mainline.

> 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. 

Unfortunately, last time I tried to have loom installed it was totally
incompatible with the bzr, bzrtools, bzr-svn I had installed, and the
only solution to having a working bzr was to remove looms.

If the loom plugin is fully compatible with bzr.dev I can experiment
again given I now run bzr.dev and not the latest formal release.

If looms can solve the easy comprehensibility of merge to mainline issue
without rebase then even better than the situation I currently have. 

> 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.

I think uncommit/recommit is a very different beast and I don't think it
should be tainted with the same brush rebase is painted with. 

> > > 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.

I am not sure it needs to be in core.  It is a controversial feature and
a plugin seems like entirely the right place for it.  OPs issue was that
there was potential uncertainty about the level of quality since it
didn't have the same review structure as Bazaar core.

> > 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.
> 
-- 
Russel.
============================================================
Dr Russel Winder                 Partner

Concertant LLP          t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,     f: +44 8700 516 084    voip:  sip:russel.winder at ekiga.net
London SW11 1EN, UK.    m: +44 7770 465 077    xmpp: russel at russel.org.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090420/3d1a2f51/attachment.pgp