Re: Premerging topics

[Antoine Pelisse <apelisse@gmail.com>]

On Tue, Apr 23, 2013 at 4:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
>
>> Can you solve this problem with a tree object, instead of inventing a
>> specially-formatted blob?
>
> Hmm.  What problem are you guys trying to solve?
>
> [snipped..]
> And that was why I wanted to have a data structure that is quick to
> query to answer "I am about to merge B.  Does the history already
> have an A for which I have recorded a merge-fix for <A,B> pair?"

That's exactly the problem I'm trying to solve.
I'm willing to have an efficient way to merge topicC that has semantic
conflicts with topicA and topicB.
As topics will be merged together first in pu, then in next and
finally in master, chances are that they won't be merged in the same
order (or then, why would we even care about a topic workflow?). And I
have the feeling that "merge-fix/B" or "merge-fix/A" doesn't hold
enough information to do that accurately.

The idea is then to store the <A, B> pair as a note, and to associate
a "merge" to that (solving the semantic conflict). It would then be
used as an implicit third parent for the merge of "branch containing
A" and "branch containing B". This is pretty much what Michael said in
the $gmane you talked about.

Cheers,
Antoine