On Tue, Apr 23, 2013 at 4:53 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Johan Herland <johan@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html