Re: whither merge-tree?

Jeff King [off-list ref] writes:

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

quoted

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.

So here is what I would propose:

  [1/3]: merge-one-file: use empty blob for add/add base
  [2/3]: merge-tree: drop generate_common strategy
  [3/3]: xdiff: drop XDL_EMIT_COMMON

I briefly wondered if there were any bugs in merge-one-file around this
"no newline at end of file" issue. But there shouldn't be. It generates
the common file by applying the diff to the first file with "--no-add",
which should do the right thing, I think.

I stopped short of dropping the create_virtual_base function in the
first patch, for reasons explained there. But if we were to do so, I
suspect we could deprecated and eventually drop "apply --no-add", too.

Thanks.  I think the "virtual" stuff started its life outside
sh-setup but later was moved there for p4merge.  The log message for
4549162e (mergetools/p4merge: create a base if none available,
2013-03-13) seems to indicate that using an empty file does not work
well over there as you suspected, so unfortunately we cannot lose it
just yet.