Re: [PATCH v2] update-ref: add --rename option

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> [Appendix]
> ...  Ideally, these cherry-pickable commits
> that are stored under refs/merge-fix hierarchies SHOULD be indexable
> by a pair of topic (i.e. "when topic A and topic B first meets, apply
> this evil merge"), but this computation is cumbersome to write.

One scheme might be to use "refs/merge-fix/$A--$B" to store the
interaction between topic $A and topic $B, with the convention that
no topic is named with double-dash in its name.

We sequencially merge these in-flight topic into the integration
branch (e.g., 'seen').  When merging topic X, we roughly would need
to do the following.

 (0) Skip if X is already in the integration branch.

 (1) See what topic Y that would also be merged for the first time
     to the integration branch.  This is because a complex topic X
     often is done by merging in-flight Y into then-current master
     and applyng patches on top, and depending on the state of the
     integration branch, such topic Y may or may not have already
     been mergeed there.  Enumerate all these topic Ys that would
     be pulled into the integration branch as a side effect of
     merging X.

 (2) Enumerate all merge-fix refs that has any of the topic Ys or X.
     For each such refs/merge-fix/$A--$B (where either $A or $B is X
     or one of Ys), call the other side of "--" Z.  If Z is already
     in the integration branch, then we found the merge-fix we need
     to apply.

The "topic X might pull other topics that haven't been merged
together with it when it gets merged" is what makes it cumbersome to
write.  If we do not have to worry about it, it would be fairly
straight forward, but then the bulk-merge driver probably needs to
learn a safety check to make sure at the point of merging each topic
that the merge is not pulling another topic (base) into as a side
effect.  It would mean that you prepare a new topic X on top of a
merge of Y into 'master', and X can never be merged into 'seen'
before Y is.  Which may or may not be what we really want, and I
need to think about it a bit.