Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Stefan Monnier writes:

 > 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.  I don't think it can be represented by an arc between
commits, because that would look like a merge, but either the content
of the parent of the base of the rebased branch is trivially merged (a
forward rebase on the same mainline) or it is not merged at all (a
cherry-pick).

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.  For example, when
somebody like Ben Finney is doing forensic analysis, bisect will
identify (a representative of) the right equivalence class of arcs.
*Most of the time* that is sufficient to localize a defect.  Sometimes
it's either helpful (psychology: what was she thinking when she wrote
this code?) or necessary (process: de workflow done make me do dat!)
to have the original context, but that's infrequent enough, and not
automatable AFAICS.  So an annotation (automatically presented, of
course) as I suggest in my other post seems like the way to go.

What do you think?

 > The rest of the history still exists but (some part of it) will
 > become GC'able, which means that this missing arc will lead to
 > futher loss indeed.

Not until the reflog expires.  Currently, the reflog in git has a
global expiration parameter, but you could set it to infinity (which
is what I do, personally), or (more flexibly) you could arrange for
per-log expirations, and have rebase set its reflog entries to
no-expire.

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.