Re: whither merge-tree?

[Jeff King <peff@peff.net>]

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

> Jeff King <peff@peff.net> writes:
> 
> >   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.

> >      That lets people keep using merge-tree if they have found it useful
> >      over the years.
> 
> >   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