Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

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

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

which not only brings the workspace back to original state but also
resets the ref to point to the original history.

 > You have talked some about the reflog, which we don't have a related
 > concept for in Bazaar (yet [1]). Am I correct in saying that the
 > reflog is local to your repository

As storage, yes.  The content of course is usable by git in any repo
that has acquired the referenced objects.

 > (it certainly isn't included in format-patch output,

I don't see how it's relevant to format-patch.  format-patch doesn't
produce a merge directive AFAIK, it produces a patch.

 > but I'm not sure if "pull" transfers it)?

As soon as people figure out how to use it to repair rebases, it will
be transfered.  Until then, there's no need, because the destination's
reflog will have all the information that we currently know how to use
in disentangling a rebase.

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

 > and you won't be able to one day.

What value of "you" do you have in mind?  *I* have gc-prune disabled
in all my active repos.  At least up to Emacs, XEmacs, and Python
scale, it's been negligible cost for me to do that.

 > This means the original revisions will be lost eventually.

Er, no.  If the "original" revisions can be lost by me rebasing, then
they haven't escaped to you.  In that case, all that has happened is
that I've deleted an obsolete experimental branch.  *This is a
documented workflow in Bazaar!*  (Cf. Mark's tutorial.)

Furthermore, even with gc-prune enabled, I bet your repos (like mine)
end up on DVD every Friday.  Since objects are immutable,

    mount /repo/2007
    export GIT_ALTERNATIVE_OBJECT_DIRECTORIES=/repo/2007/project/.git/objects
    cp /repo/2007/project/.git/refs/heads/lostit .git/refs/heads/foundit

and Say hey, Willie Mays!  The Dead Sea Scrolls have been unearthed!
History is not lost!!!!!!!

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

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!

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

The point of rebase is that it allows the *user* to say what she wants
optimized in a very natural way.  Appropriate use of reflogs should[1]
allow reconstruction of the view of history that David Strauss
advocates.  It would be an option slightly more expensive than default
git behavior, but nowhere near as heavy as bzr log seems to be, even
in bzr.dev.


Footnotes: 
[1]  I ain't done it, true, and I may be misreading his preference.
But seems very plausible.