Will re-basing support be added into Bazaar core ?

[Andrew Bennetts]

I'm finding your mails to be extremely frustrating.  I think maybe you are
trying to argue that some of my assumptions are wrong, but you're doing it
with misinterpretations and strawmen, rather than by directly saying
whatever it is you want to say.

Stephen J. Turnbull wrote:
> 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.

I have made no statement about the quality of the implementation in the
bzr-rebase plugin.

What I am making statements about is how rebase, as a general concept, takes
some tip and outputs a new tip, and how that new tip's ancestry will not
contain revisions found in the original tip's ancestry.  Whether or not
those revisions are still in the overall DAG of some particular repository
and thus theoretically accessible and resurrectable is, as you say, an
implementation detail.

If your new tip does have references to those original revisions, but those
references are part of something other than the ancestry, then it seems to
me like you have a more complicated model.  That might be reasonable, but
it's far from clear to me that the extra complexity is obviously superior.
Or to put it another way: if a revision has two parents (the point in trunk
you are based off, and the original revision before rebasing), why not
record that as a merge revision?

> 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 do not appreciate your strawman here.  I never said that anyone was
recommending rebase as a tool for all seasons.  I am well aware that Linus'
says that rebase has drawbacks and should be used in moderation.  I have not
used the word “evil”.  I have not said there is never an advantage to
rebase, and I even described it as “genuinely useful” in my original mail to
this thread.  If you want to debunk those claims please direct your mail to
to the inbox of someone that has actually made those claims rather than put
words in my mouth.

What I do claim is that rebase alters the history of a branch.  In bzr (the
topic of this mailing list) this is clearly true, as there is no way to make
a revision part of a branch except via the branch's ancestry.  So performing
an operation on the branch that results in a new ancestry that does not
contain that revision is removing history from that branch.  You could add a
revision property to name a revision not in the ancestry, but that won't
automatically lead to those revisions being copied by push, pull, send or
merge, so they may as well not be there, because other people will never
receive those revisions.  This is not a problem with a loom.

Even in git, with its implementation of rebase and the “flexible
history-traversing” you describe, it still sounds like the original
revisions are second-class history.  They aren't transferred yet, although
you bet they will be soon, so those commits can easily be lost (perhaps
you'd object less to “history-losing” than “history-destroying”).  You say
the rebase proof-of-concept had a flaw that would make those commits
garbage, the loom proof-of-concept has no such flaw, because the design is
different.

Further, it seems to me that rebase users often use it precisely because it
alters history.
<http://www.kernel.org/pub/software/scm/git/docs/user-manual.html> has a
chapter titled “Rewriting history and maintaining patch series” to pick one
example.  If you run git rebase -i you're given a file to edit with the
warning that “If you remove a line here THAT COMMIT WILL BE LOST.”  Perhaps
you need to debunk git's manual and builtin warnings!

The sense in which history is not “altered” or “destroyed” by rebase seems
pretty irrelevant to how and why many (most?) people use rebase.

[...]
>  > 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!)

I would like if that happened too.  There is no place in the current formats
for such thing to happen without using the ancestry (or potentially tags...
ugh, and besides there are bugs there...).

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

I am aware of this.  I'm not sure if you do understand what bzr-loom does.

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

Sure.  I can't speak for other projects obviously, but there's pretty clear
agreement in this community that bzr could (and should) do better.  I
certainly think so.

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

Looms do not have this flaw.  You seem to be arguing that they are
theoretically equivalent, but clearly they are not so in practice!

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

Yes, bzr should do better at giving you a coherent view of multiple
branches.  As mentioned in a previous thread tools like qlog have started
doing this, and I expect some of that work will end up in the core sooner or
later.

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

It's not particularly relevant to the debate, but I was erring on the side
of too much precision.

It is like dropping a patch from the patch series.  In rebase terms it would
be equivalent to e.g. "take revisions 1, 2, 4 and 5 (and forget 3)".  I
assume git's rebase -i allows this.

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

The following sentence states 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 be utterly precise: yes obviously applying plains diffs and similar
actions will of course lose revision metadata.  This is independent of
rebase vs. loom though.

The difference I am highlighting here is that no loom operation will lose
that revision metadata, or disassociate it or downgrade it to some sort of
second-class reference that gitk won't notice.  It is a regular part of the
branch's ancestry, like any other merge.  This is different to rebase.

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

But loom does record it: it's a merge.

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

I think you can assume I've read Mark's messages.  <wink>

-Andrew.