On Tue, Feb 23, 2016 at 12:02:10AM -0500, Jeff King wrote: > > git-merge-resolve (rather, git-merge-one-file) attempts the same > > "resolve add/add by taking the common" thing, but it implements it > > in quite a different way. > > I suppose the end result of what merge-tree is trying to do makes sense. > It's definitely a conflict, but we are interested in showing the minimal > content-level conflict. But I think xdl_merge() takes care of that for > us, if we simply feed an empty base. And that is what merge-recursive > does. > > I do see that merge-one-file tries create_virtual_base(), which does > some magic with diff. But I'm having trouble conceiving of a case where > that would do something different or useful. I dug this all the way down to your cb93c19 (merge-one-file: use common as base, instead of emptiness., 2005-11-09), which states that the goal is just to get: common file contents... <<<<<< FILENAME version from our branch... ====== version from their branch... >>>>>> .merge_file_XXXXXX more common file contents... But that seems to be what we produce now. Did all of this simply predate xdl_merge, and the crappy rcs merge did not bother minimizing the diff? That certainly seems to be the case in my tests. If that is the case, I think we can get rid of the complex create_virtual_base(), as well. -Peff -- 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