Will re-basing support be added into Bazaar core ?

[James Westby]

On Mon, 2009-04-20 at 23:26 +0900, Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
> 
>  > Second, it creates a history that you never actually had.
> 
> So do the manipulations performed by looms and friends.

Yes, that is unavoidable. However, merging will do "less" of that.

If I have a branch that has two revisions added when compared to
yours, and I want to incorporate some revisions of yours, then I
can merge (looms) or rebase.

If I merge, then the two revisions I did remain the same, and I create
one revision containing the merged contents. I can then test this and
commit it, just as if I had just written all your changes myself
in the working tree and committed.

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.

That's the inherent difference between the two. To me it's not a
huge issue, as old revisions tend to start failing tests over time
anyway (as the world moves on in the meantime), and of course they
are not perfect anyway.

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.

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

I have no problem with rebase as a tool, and wouldn't mind having it in
the core. In particular "rebase -i" would be very useful sometimes.

Thanks,

James