Fixing rebase rather than avoiding it

[Stefan Monnier]

>> Well, you get a new branch that doesn't explain its relationship with
>> the old branch.  That's the part of the history (i.e. one arc in the
>> DAG) that's actually really lost.
> Thing is, that's an annotation, a meta-arc.  Ie, a parent-child
> relation between arcs, while an arc is a parent-child relation between
> commits.

It is an arc.  Or rather, since the two commits have identical contents,
the two commits should be merged, which is why I'm saying it should
simply modify the existing commit by adding to its history.

> I don't think it can be represented by an arc between
> commits, because that would look like a merge,

What's wrong with that?

> I agree we'd like to be able to represent that idea, but I'm not sure
> how big a loss it is for day-to-day operations.

Let's simply imagine that you want to rebase a published branch.
Of course, it's currently not a "day-to-day" operation for one good
reason: current "rebase" would screw everyone who branched off of
that branch.

> More important than the issue of expiration itself, I guess you would
> need to propagate those no-expire entries.  I don't know whether you
> would necessarily want to propagate the corresponding obsolete branches.

Whether they get GC'd or not is irrelevant: as long as the connection
between the new commit and the old one is not recorded and usable by
"pull/merge", you won't be able to use rebase on a published branch.


        Stefan