Re: Premerging topics

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

Johan Herland <johan@herland.net> writes:

>> But P is a commit(/merge with two parents), not a blob. Can we have trees
>> pointing to commits instead of blobs ?
>
> Sort of. We do so when recording submodules in regular git trees.

You are using notes to maintain reachability, aren't you?  Because
commit objects that appears in trees are not treated as reachable
from the trees, that won't fly.

I think you guys are making it unnecessarily complex by using notes.
To record a prepared evil merge for merging branch that contains A
with another branch that contains B (assuming that the interation
between A and B is what makes the evil merge necessary, e.g. A
renames a function foo() to bar(), while B adds new callsite that
calls foo()), we can store a single commit that records the prepared
evil merge under "refs/merge-fix/$A-$B" where A and B are their
object names.

Then when merging a branch Y that contains B into our history X that
already contains A (or vice versa),

  ---o---o---A---o---X... ???
      \                  .
       \                .
        \              .
         o---B----o---Y

we can enumerate the commits that appear in "log --left-right X...Y"
on the left/right side and notice there is refs/merge-fix/$A-$B.

So the simplest implementation of "an efficient data store to record
a commit for <A,B> pair" turns out to be just a ref namespace ;-)

There may be other <C,D> pairs in X...Y history, and it probably is
the sane thing to do to replay prepackaged evil merges from older to
newer in the topological sense, but that loop would be trivial, once
we understand how to replay a single such evil merge.

The actual merge-fix data should be just a commit with a single
parent. The easiest way to prepare it would be like this:

  ---o---o---A
      \       \
       \       M---F
        \     /
         o---B

where M is the result of mechanical merge between A and B (there
could be textual conflicts and you could choose to leave them in, or
you could choose to have rerere resolve it.  As long as you do the
same when replaying this prepackaged evil merge, this choice does
not matter, but using rerere will make your life easier), and F is
the final result you would want, with semantics conflicts resolved.
In other words, in the ideal world, you would have resolved a merge
between A and B to record the tree of F.

Point "F" with refs/merge-fix/$A-$B and you are done.

When you replay this prepackaged evil merge, first you mechanically
merge X and Y without worrying about M or F to produce N.  If you
allowed rerere to resolve textual conflicts between A and B when you
recorded M, allow rerere to resolve this merge.  Otherwise leave the
textual conflict in.

  ---o---o---A---o---X
      \               \
       \               N
        \             /
         o---B---o---Y

Then on top of N, you cherry-pick F, which will bring the semantic
conflict resolution between M and F on top of N.

  ---o---o---A---o---X
      \               \
       \               N---F'
        \             /
         o---B---o---Y

Once you know the tree shape of F', then you no longer need N.  Just
amend it away and make the tree recorded in F' the result of the
merge between X and Y.

  ---o---o---A---o---X---.
      \                   \
       \                  F''
        \                /
         o---B---o---Y--.