On Wed, 18 Apr 2007, Junio C Hamano wrote: > > While I agree with all of the above, I am currently fighting > with a back-to-drawing-board design problem. > > The series made the low-level 3-way merge machinery > customizable, which is a progress, but I think merge-recursive > needs a hook to affect middle-level merge decision, similar to > what git-merge-one-file does. Hmm. I think that it's not so much a "hook", as a "recursive merge is a separate merge policy altogether, that just *defaults* to the same final merge policy". For example, for a three-way merge, it makes sense to do the three-way merge for the "internal" merge too. But it might be that that isn't true for all strategies. For a "blend" merge, blending at the middle level might be the wrong thing to do because it might duplicate the messages, for example. So maybe the rule could be: - for a file with merge strategy "xyzzy", a recursive merge will first look up the merge machinery for "xyzzy-recursive" and if no such merge strategy exists, it will look up merge machinery for "xyzzy". - the final merge will always use merge strategy "xyzzy". So then, assuming I'm right that the "blend" strategy needs soemthing else in the middle (and I'm not sure I'm right at all, this is purely hypothetical ;), you could have something like # a recursive merge will always just pick the ORIGINAL # version of a file when blending - the blending will # be done only on the final merge [merge "blend-recursive"] name = recursive blend strategy driver = cp %O %A [merge "blend"] name = blend (changelog) strategy driver = blend %A %O %B or something like that? I _suspect_ that most merge strategies want to use the same strategy for the recursive merge as for the final one, but I haven't really thought it through. Linus - 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