Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

Ben Finney writes:

 > Note that we're specifically talking about rebase, not other Git
 > operations. As I understand it from your descriptions and others
 > <URL:http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/>,
 > rebase makes the revisions *not there anymore* in the branch history.
 > Whether they're still in the repository somewhere isn't relevant to
 > this point: they're gone *from the branch*.

Two answers.

(1) reflog.  After a rebase of 'foo', "foo@{1}" is a reference to the
    The Artist Formerly Known As foo.

(2) You're reifying "ref is branch" in a way that is entirely
    inappropriate for git.  See (1).

 > > Exactly the same is true for loom, right down to the "(you hope)".
 > 
 > That's the significant difference I'm pointing out with a loom:
 > revisions never go away from the branch, but new ones get added.

Sure, given the way you reify references, that's going to make a big
difference.  You will be much more comfortable if you avoid rebasing
as much as you can.  For me, it makes for more sense to use rebasing
(as I feel appropriate), and improve the VCS to use the reflog to make
appropriate identifications/equivalences of revisions.

 > > The only difference is the UI by which you refer to the new and/or old
 > > revisions (ie, how you get them to manifest in a workspace so you can
 > > build and test them), and how they are represented in the VCS
 > > database. Git doesn't distinguish between revisions "as they happened"
 > > and "as they are rebased". Loom does distinguish between "revisions"
 > > and "threads". Purely UI.
 > 
 > What you call UI in this context, I call the data model. The data model
 > in rebase is that history, as modelled by the tool and presented to the
 > user, is altered. With a loom, that's not true.

The data model in rebase *for Bazaar* may be to alter history (but see
my response to Robert Collins and the example of recovering a lost
branch shown there), because Bazaar does reify history into "what's in
the branch".  That is not true for git, where what users usually call
branches are just refs, and history is immutably embedded in the
repository's object database.  "Presentation to user" is obviously UI.

 > Exactly what am I supposed to grok, and what FUD am I currently subject
 > to?

The difference between the content of a branch, and a ref to that
branch.  The FUD you are subject to is the notion that rebasing in git
"destroys information" or "alters history".  It does neither.  It
simply changes how history is referred to, and which part of history
or aspect of history is most easily referred to.  The "rebase problem"
really is just the Humpty Dumpty problem ("when I use a word, it means
what I want it to mean, and nothing else"; for git, s/word/ref/ and
s/what/the commit/).

 > > You may learn to hate git like a Martian, but you'll stop fearing it.

Cf. Robert Heinlein, _Stranger in a Strange Land_.  I don't have a
copy any more so can't look it up, but in the Martian language the
word for love, hate, and "full understanding" is identically "grok".