Will re-basing support be added into Bazaar core ?

[Robert Collins]

On Wed, 2009-04-22 at 14:24 +0900, Stephen J. Turnbull wrote:
> James Westby writes:
>  > On Tue, 2009-04-21 at 16:29 +0900, Stephen J. Turnbull wrote:
>  > >  > Rebase does not preserve existing history.
>  > > 
>  > > In git, it does, by construction.  What it doesn't preserve is the
>  > > value of the ref.
>  > 
>  > I think this is one of the crucial difference in viewpoint in this
>  > thread.
>  > 
>  > While what you right is absolutely correct, I think most heavy Bazaar
>  > users would say that value of the ref is what is crucial, so your
>  > point here does not make much sense.
> 
> Sure.  Heavy Bazaar users have learned to reify the *name* of a branch
> as *being the branch* which is often in real life a *multimegabyte
> directory tree*.  This leads them to internalize FUD like "rebase
> destroys history".

I don't think that its fud. Sure it doesn't destructively delete
revisions, but I'd be repeating things if I went into that.

> Thing is, with git if you have the least qualms about what you are
> about to do to your branch, you just do "git tag save-my-branch" and
> (short of bugs or hardware failure) your history is safe *forever*.
> You can revert the branch very quickly with
> 
>     git checkout -f -b my-branch save-my-branch

bzr tag save-my-branch
bzr pull . -r tag:save-my-branch

Other than that s/git/bzr in your previous paragraph.


>  > If so then it's locality seems to limit its use. Yes, the original
>  > revisions are still in your repository, but I can't see them,
> 
> Oh, but you *can*!  In fact, that's *precisely why rebase is
> poisonous*.  If you *can't* see the old history, you will have no
> problem pulling the new history, and be none the wiser.
> 
> The problem with rebase is that what you think should be a fast
> forward pull (since you've never merged the branch locally) turns out
> to be an 800-lb gorilla of a merge because there are many duplicate
> (or worse, altered-during-rebase-near-duplicate) patches involved.

This is definitely one of the problems with rebase (and again, something
loom doesn't suffer :)).

>  > Your point above is entirely correct, but if it wasn't then git
>  > would be useless as a DVCS, so I think you need to explain what
>  > benefit there is in this.
> 
> A rebase is a merge, and has the same benefits as any other merge.

I would argue that it is not a merge, or that there is a term which
people mean when they say merge that merge (in git, hg and bzr) meets,
but rebase (in git, hg and bzr) doesn't.

rebase isn't a merge in the same way that cherry-pick isn't a merge; the
DAG isn't transitively joined between the two tip refs. Yes code is
combined (with caveats on testing, which cherrypick also suffers).

An aside: rebase is arguably best defined as repeated cherrypicking.

> The advantage to rebase over a 3-way merge is that the changes on a
> long-lived feature branch are contiguous in a DAG, and therefore
> operations like log, diff, and bisect on that branch are optimized.
> Has Bazaar already improved to the point where optimizations are
> unnecessary?  I think not!

You are conflating many unrelated things.

Let me separate them:
Why is diff slow in bzr? Because diff(tree1, tree2) requires
size-of-tree decompression and comparison. This is fixed in
development6-rich-root.

Why is bisect slow? Likely, most probably in fact, because diff is slow.
I haven't profiled bisect so don't know for sure. Anyway, regardless of
DAG complexity, starts with a O(left-hand-history-length) operation, and
from then on has stop-revisions which reduce the history examination by
50% each step. A linear DAG may well have more left-hand steps to take
than a complex DAG merging in multiple commits as feature-branches - so
in theory could be faster.

Why is log slow? Because we show dotted revnos and have neither a cache
with a sufficiently good set of tradeoffs (Ian is working on this) nor
decided to either remove them or alter their definition to be more
friendly to caching. There is strong support in the bzr userbase for
dotted revnos - removing them isn't a no-brainer. log -v is slow because
diff is slow (see above).

>  > Otherwise it seems repeatedly arguing on this point is merely
>  > trying to pick fault with a slightly sloppy use of terminology,
>  > when if there is not benefit that sloppy use isn't really
>  > misplaced.
> 
> I'm sorry, but when people say that rebase destroys or alters history,
> that's not "slightly sloppy", that's FUD.

There is a very obvious disconnect here. You interpret 'destroy' or
'alter' history as 'mutate or delete commit objects'. I believe that
nearly all the users *in the world* when discussing this topic would
understand 'rebase destroys or alters history' to refer to removing the
prior branch ref and replacing it with another that does not refer to
the original ref. reflogs are not equivalent to refs! (I suspect that
gitk doesn't show older refs found in reflogs, for instance). Its true
that the underlying facilities in git can recover the old ref - but log
won't show it [by default], nor will the older ref propogate any more,
its not used to aid in merge - I could go on.

I appreciate the need for rigour in discussing what is really going on,
but I put it to you that 'history' most commonly binds to 'what is
reachable by the tip ref for a branch'. Sloppy thinking is not
necessarily involved.

>   When gitk can put up the
> entire DAG of Linus's repo before bzr output the log for the head
> commit, that's room for optimization.

Absolutely.

-Rob
-------------- 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/20090422/4235e64f/attachment.pgp