Re: whither merge-tree?

On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

  2. Rip out the weird add/add conflict resolution. This gets rid of the
     buggy code, makes merge-tree more like the rest of git, and I think
     lets us even drop the EMIT_COMMON stuff from xdiff).

That is a nice bonus.

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.

quoted

     That lets people keep using merge-tree if they have found it useful
     over the years.

quoted

  3. Drop merge-tree completely. This deletes even more code, and helps
     the people in (2) realize that it is utterly unmaintained. :)

I think at this point I am waffling between (2) and (3). I did (1) in a
hope that I could avoid looking deeper into the code at all, but now
that I have, I do not think (2) would be so bad. I'm happy to work up a
patch, but won't bother if we think that (3) is viable.

Yup, between 2 and 3, 2 would certainly be safer, and I agree that
it is not too bad (I have this feeling that add-add conflict is not
the only funny this code has, though).

Yeah, I do not mind doing 2, but I have no idea what else is lurking,
and I have very little interest in digging into it.

Let's wait and see how many "please don't"s we hear, perhaps, before
deciding to go 3.?

I'm guessing we won't see much either way. Even Stefan, the original
reporter, does not seem to actively be using it, but rather relaying a
report.

We'd probably get more response by doing 2 for now, then adding a
deprecation warning to the manpage (and possibly the program itself) for
the next release.

-Peff