Will re-basing support be added into Bazaar core ?

[Stephen J. Turnbull]

Andrew Bennetts writes:

 > My two statements are entirely consistent and accurate.  I'm
 > clearly meaning "the revisions in the ancestry of the branch" when
 > I'm referring to history in both of those statements.  This is the
 > same sense used by e.g.  "bzr revision-history".

Use the wrong tool, get the wrong result.  *Rebase* is a more general
concept than bzr's rebase plug-in, and I am not at all surprised if
bzr revision-history fails dismally to deal with rebase in a sane
way---it simply is not designed to do so.  As I pointed out to Ben, if
you think about things in terms of The Bazaar Way (and Ian's
protestations about Adaptable Bazaar notwithstanding, bzr is not very
flexible about this, cf. Robert's and David Cournapeau's comments),
rebase is crazy.  But that's an implementation detail.  If you like
your implementation, avoid rebase.

However, AFAICS the rebase "advocates" are not calling rebase "a tool
for all seasons."  There are well-known difficulties in coordinating
refs in a distributed project, and at least for now those difficulties
should be avoided.  We all admit that, even Linus.  But it's easy to
do so, so rebase can be a useful tool/optimization.  Unfortunately,
the Opposition uses terms like "evil" and suggests that there is
*never* an advantage to rebase, and spreads FUD like "history-
destroying" and (more plausibly, but still wrong) "history-altering".
That's what I'm interested in debunking.

I'd also like to see bzr get a flexible history-traversing (*not*
"history editing") mechanism like git's.

 > Rebase does not preserve existing history.

In git, it does, by construction.  What it doesn't preserve is the
value of the ref.

 > It's not enough for the newly synthesised revisions to have
 > properties naming the original revisions if those revisions will
 > not be transported when someone else pulls/merges/whatever the
 > rebased branch into their local copy.

True.  What I would hope for from Bazaar is an implementation that
*does* take care of those details.  I will put money (or beverage of
choice) on it that git will have such features within one year from
acceptance of the bet.  (The reflog and .git/info/grafts makes it
low-hanging fruit, don't accept that bet!)

 > Loom does preserve history.  It strictly only adds to the DAG.

This is true of git as well.  "Branches" in the sense that you think
of them---as a strong association among a name, a working tree, and a
linear history of development---*don't exist* in git.  There are
*refs* (analogous to symlinks in a file system, Lisp symbols, or
Python identifiers), which point into the DAG from outside, and there
are *commits*, which are DAG constituents.  In git, if you want to
reify history into an object, well, you are talking about a commit,
and commits are immutable.

Commits *can* become garbage, and be collected, but rebase (in recent
git) doesn't create any garbage, although the initial proof of concept
script did.  Note that gitfolk learn from experience: filter-branch
made sure it hangs on to the old ref by the old name from the time it
was introduced.

IMO, it *is* useful to associate a name with a sequence of commits.
But all the current market leaders get it wrong (IMO).  Darcs is
ahistorical and can't even represent the DAG AFAIK.  git provides no
association: there's no easy way to find the former referents of
rebased or otherwise reused refs, and they don't appear in gitk.
Mercurial puts the originating branch name into commits, but if two
branches happen to get merged and synchronized, one loses its identity
because there's only space for one branch in a commit.  bzr gives you
tunnel vision, so it's hard to visualize relationships among unmerged
branches, although it is quite good about providing good ways to
explore past merges.

 > The only exception is when you a remove a thread;

How does this map to "rebase"?  Or is it irrelevant to the loom
vs. rebase debate, except in the sense of a feature possessed by loom
that rebase can't even represent?

 > in that case any revisions not present in the later threads are no
 > longer referenced -- but then their corresponding textual changes
 > are not either, which is the point.

I don't understand the point.

 > If you have a change, you have the revision where that change
 > originated.

You do?  In general, "the origin" might be a patch against a different
branch with a very ambiguous relation to any of the "official"
branches in the project (this happens in XEmacs and Python development
all the time).  I don't understand what you mean by "*the* revision",
or how you "have" it.

 > > To unpack that, a loom (stack, quilt, or queue) allows you to very
 > > flexibly modify working trees automatically according to a history-
 > > conforming framework (up to patch application conflicts, which are the
 > > same as merge conflicts), just as rebase does.  The only difference is
 > > that it doesn't record that creation in the VCS history.  You still
 >        ^
 > 
 > Does "it" refer to loom or rebase in that sentence?

To loom.  It can't refer to rebase, because in rebase there must be a
commit or you can't refer to it via the VCS.

  > > did it, though, and it is history in that sense.

[...]
 > I think you are thinking about looms in a weird way

It's taken you this long to notice?!  To quote Mark Shuttleworth,

    However, I think the Bazaar team needs to recognise that existing
    evolutionary processes have resulted in a poor UI experience,
    despite having lots of good people who feel like they care about
    this.

You *desperately* need *more wackos*.  I think I qualify!<wink>