Will re-basing support be added into Bazaar core ?

Andrew Bennetts andrew.bennetts at canonical.com
Tue Apr 21 06:43:56 BST 2009


Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
>  > Stephen J. Turnbull wrote:
>  > > Andrew Bennetts writes:
>  > > 
>  > >  > Second, it creates a history that you never actually had.
>  > > 
>  > > So do the manipulations performed by looms and friends.
>  > 
>  > No, looms do not modify or discard any history.
> 
> Reread what *you* wrote: "create".  As I responded to David, any
> feminist will tell you that the fact that history isn't recorded
> doesn't mean it didn't happen.

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

Rebase does not preserve existing history.  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.

Loom does preserve history.  It strictly only adds to the DAG.  The only
exception is when you a remove a thread; 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.  If you
have a change, you have the revision where that change originated.

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

> did it, though, and it is history in that sense.
> 
> The question of to what extent traversing a "parallel" path in the
> tree DAG (the "static" DAG which has all trees as nodes and formally
> links them by the process of "arbitrary edit") corresponds to
> traversing the "same" path in the commit history DAG is a very
> delicate question.  Bzr (and other branch-is-working-tree-oriented
> VCSes) encourages the point of view that history is an object reified
> in the working directory.  Darcs (and other recombinant patch systems
> like looms) tend to deprecate the idea of "history" entirely, except
> as an accidental, mostly arbitrary sequencer for patches.  Git is
> somewhere in the middle.

I think you are thinking about looms in a weird way if you find them to be
more like Darcs than like a convenient collection of bzr branches with some
simple workflow-helper commands.  Everything the bzr-loom plugin does is
possible without using the plugin, just with a little more tedium.  The DAG
of revisions still works exactly the same way whether you are using a loom
or not.

-Andrew.




More information about the bazaar mailing list