Re: whither merge-tree?

From: Jeff King <peff@peff.net>
Date: Feb 23, 2016, 05:02 UTC
Message-ID: <20160223050210.GA17767@sigill.intra.peff.net>
In-Reply-To: <xmqqsi0k4b52.fsf@gitster.mtv.corp.google.com>

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

Show 11 quoted lines

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

Show 14 quoted lines

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