Fixing rebase rather than avoiding it

[Stefan Monnier]

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

Keeping track of the real history of a branch (for forensic analysis for
example) might be important, but then rebase tends to be undesirable in
such a context since it tends to lie about the actual order in which
code was written.

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

>> This would make it perfectly acceptable to rebase a branch that's
>> published, i.e. it would eliminate the reason to discourage the use
>> of rebase.
> 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.  That's one
of the cases of interest to me; and in that case adding an arc is
perfectly acceptable.

In the case where the rebase is to a branch that's "unrelated", then
indeed my proposed-rebase wouldn't be applicable (at least not without
more work).

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

>> E.g. when rewriting revisions A1-B1-C1 to A2-B2-C2 by removing some
>> of the files, the resulting revisions should not look like:
>> 
>> A2 -> B2 -> C2
>> 
>> but
>> 
>> A2 -> B2 -> C2
>> ^     ^     ^
>> |     |     |
>> A1 -> B1 -> C1

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

> Also (nitpick) the implementation of the links will go in the reverse
> direction (the child points at the parent).

Indeed, sorry, I had my arrows point to the children.


        Stefan