Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > Nevertheless, IMO it should not be able to do it.  Ancestry is what
 > > makes two commits with other metadata identical into different
 > > commits, and for a number of reasons (forensic analysis as Ben Finney
 > > mentions, intended presentation by authors, etc) I think that parents
 > > should remain part of the identity of commits.
 > 
 > The info about intended presentation can be stored in many different
 > ways, so it doesn't necessarily care whether the parents are part of the
 > identity of a commit.

True.  However, the idea gives me the willies (== if you try it and it
turns out to be a screwup, I reserve the right to say "I told you
so!" :-).

Also, be aware that you're on a slippery slope, whose bottom is
"commit == tree, all else is modifiable annotation".  This is
unsatisfactory, because you end up losing all sense of history.

 > Another way to look at it: having parents be part of the identity of
 > commits is similar to keeping track of "file-ids" which Bzr uses to
 > track file-moves.

I strongly disagree with that.  A commit is not a container for a
tree.  A commit is a node in the history dag, and the tree is just an
annotation.

 > Notice that Git prefers to do away with it and stick to a more
 > "shallow" handling of data for file name histories, but not for
 > revision history.

Indeed.  Vary from the designs of a genius at your peril!

 > > This is incoherent, however.  Remember, a rebase is conceptually
 > > moving an arc, while a merge creates new ones.  Also, the content of
 > > the *old* base is *not* merged; the rebased branch really has been
 > > severed from that ancestry.
 > 
 > A rebase such as the one I propose is indeed a different beast from the
 > current rebase.  The current rebase takes a set of patches and applies
 > them to a branch.  If the new base is (transitively) a child of the old
 > base (as is the case in many usage scenarios, but clearly not all), then
 > the resulting file contents should be identical to a merge.

The question is, *which* merge?  I think it's quite plausible that
users would resolve conflicts differently if they occur in a grand
merge of two branches vs. resolving them commit by commit in a
rebasing process.

 > That's one of the cases of interest to me; and in that case adding
 > an arc is perfectly acceptable.

Except to the person who's doing the rebase.

I am quite sure that I would not use your rebase for the case it's
designed for, though.  If I wanted the original base (or original
commits) to show up as a parent(s) of the rebased branch, I'd use a
proper merge.  The point of using rebase is to get rid of those arcs
when there is no conceptual dependency (ie, conflict with the new
base).  So those arcs need to be hidden, or at least hideable.

 > >> So if he's got the parent' head he'll want to use the rebased
 > >> history, whereas if he's got some old head of the branch, he'll
 > >> prefer to use the non-rebased version of the history.

 > > I suggest he probably should be told that he has the non-rebased
 > > version, and be asked whether he wants to update to the post-rebase
 > > version or do something else.

 > For typical uses of rebase (where it's used as an alternative to merge),
 > such a warning would just be annoying.  But, I could live with it
 > ;-)

Doing without the warning will surely screw people.  Even a forward
rebase on the same mainline can run into conflicts.  Any action that
can cause conflicts should not be done without warning the user that
they may need to resolve conflicts.

 > > This can only work *well* if the vertical links are different in kind
 > > from the horizontal ones.
 > 
 > I'm not completely sure that's true.  But yes, as mentioned, we'd
 > probably want to keep track of the intention behind the arcs.  This
 > is not completely new, tho: Bzr already has the notion of "leftmost
 > parent" for very similar reasons.

Implementation-wise it would be quite different.  git also has a
notion of leftmost parent, as Teemu demonstrated to Óscar.  This is
just an artifact of the ordering property of vector indicies.