Re: whither merge-tree?

From: Jeff King <peff@peff.net>
Date: Feb 23, 2016, 05:14 UTC
Message-ID: <20160223051402.GA23375@sigill.intra.peff.net>
In-Reply-To: <20160223050210.GA17767@sigill.intra.peff.net>

On Tue, Feb 23, 2016 at 12:02:10AM -0500, Jeff King wrote:

Show 13 quoted lines

> > 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