looms v. rebase (or, Where are the blogs?!) [was: Re: Will re-basing support be added into Bazaar core ?]

[Stephen J. Turnbull]

Andrew Bennetts writes:

 > Er, no, you didn't.  My name and email appears in the To: header, and
 > bazaar@ only appeared in the Cc:.  Your message quotes a message I posted,
 > and is formatted as paragraph-by-paragraph response to the contents of that
 > message.  If that's not directed to me then no email is.

*sigh*  I've obviously yanked your chain to the point where you'll
argue anything just to oppose me.  Sorry.  I will make it a point to
remove your address from emails posted to the list.

 > > Except that it's not clearly true, as both Robert and I have
 > > demonstrated.  It *is* possible to maintain multiple heads in a Bazaar
 > > branch, just very tedious, so operations similar to rebase (preserving
 > > history) are apparently possible.
 > 
 > Yes, as far as I can tell the underlying behaviour of bzr and git here are
 > very similar, although the UIs differ.
 > 
 > And in both cases, the history of your
 > branch/line-of-development/flibble-wobblet has *changed*, and that change
 > has ramifications on fetching those things and viewing their contents.

In git, a branch/line of development is a linked list.  All that
changes is the expression used to fetch the head.  After that, it's
all chasing links from one object to the next.  In other words, what
you're saying is the moral equivalent of saying that by mv'ing the
directory containing a bzr branch you've changed its history.  Is that
OK with you?

 > And every Bazaar download could include a free pony, too, if
 > someone would just make the change...  It's not enough to point at
 > an already recognised problem and say "you should change that".
 > What sort of change do you think we should make?

Do you really want to know?  Then I'll tell you.  Put the whole thing
to one side, and rebuild from scratch on top of the git object
database model.  I don't know enough about bzr internals to be able to
guess how hard it would be to support bzr's UI on top of that, but I
bet it would be performant enough to solve this problem, which AFAICS
is blocking what is really your best bet for World Domination:

 > The relevant developers have been busy working on other things
 > [besides Loom], sadly.

[...]
 > That doesn't seem to have stopped you from making statements about
 > its capabilities vs. rebase!  So far you've given every impression
 > of being certain about your understanding of what looms can do,
 > even when developers dispute your statements.

Developers have said "you're wrong", indeed.  But there's been dead
silence about what's *right*.  You fix that later in your message
(finally! oops, that's a sigh of relief, not of complaint).

As for comparing looms to rebase, the very high level purpose is
clearly the same: to more or less automatically apply, unapply, and
reapply changesets in batches.  I am quite certain of that, yes.  I'm
also quite certain that looms are more flexible than rebase.

 > >  > 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").
 > > 
 > > "Soon" is under the control of the user.  By default it's 60 days.
 > > Note that if you have a reasonable backup regime, you probably have 10
 > > copies of that history.  And those are true, verifiable copies by
 > > construction.  If you can name it, you can verify it.  "Lost"?  I
 > > suppose so.
 > 
 > "I have a backup somewhere so my VCS doesn't matter" is a pretty weak
 > argument for a VCS feature!

No, it's a very strong argument for providing automatic garbage
collection to users who care about space usage: they can move their
inactive history offline, if they want to, and access it as a
*integral part of*, not *replacement for*, the active history.

 > This is true, although it's hardly a fundamental flaw with the
 > design [of Loom], it's just something that needs some UI polish.
 > Do you have a time machine I can borrow so I can get more work
 > done?

No, but if somebody would convince me that bzr/loom offers something
to me that git/rebase does not, I could probably do that kind of
thing.

 > I welcome your insights.  I'm just not particularly interested in
 > arguments that rebase doesn't do X or Y for some definition of X
 > and Y that only you seem to use

At least I *have* a definition of "alter history" and "destroy
history", and it's consistent and very simple to state: the ancestry
relations among existing revisions are corrupted or lost.

So what's your definition?  Specifically, it needs to address the
following scenario.  In git it's conceptually easy to break the rebase
operation into two parts: create and apply the patches, then switch
the ref to the new head.  Would you still say that "history is
destroyed/altered" if the second step was omitted?  Ie, if the
original ref was left pointing to the same revision, and a new ref
created for the new head?

 > > Is there a publicly available moderately complex loom and/or
 > > script to produce one for me to look at?
 >
 > I'm not sure that a screenshot would be particularly illuminating.

No, it wouldn't.  That's why I'd like to see a good example of a loom
in progress in qlog or viz.

 > A loom is basically colocated branches + some commands for a particular
 > workflow + some support for versioning what the collection of heads is.

Thanks for the description; that helps a lot, although how this is
useful in practice is hard to visualize still.

 > In the loom workflow, you still have R in the ancestry even after updating
 > my work for changes in trunk.  The original commit, with original message
 > and original date and signature and annotations are still there.

But those changes for updating will show up in diffs, right?  How do
you filter the spurious changes out?

 > In another mail you say:
 > 
 > > While reading John's reply about previous head as a property and
 > > thinking how it sounds similar to the git practice of keeping reflogs,
 > > etc, it occured to me that an important difference in patterns of
 > > thought here is that git users generally do not think of history as
 > > being "contained in branches," while you pretty clearly do.
 > 
 > I'm glad you finally noticed! ;)

Oh, I noticed years ago.  I just couldn't (still can't, really)
believe that you're willing to constrain your users to such a
one-dimensional view of reality.