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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
