Re: whither merge-tree?

On Wed, Feb 24, 2016 at 08:28:59AM +0100, Dennis Kaarsemaker wrote:

quoted

So that's a "please don't" leave the code as-is but provide a 
(transitional) solution that fixes the reported bug and has the best 
chances of not causing any more headaches :)

I am also actively using it. It's the only way (I know of) of trying to
preview a merge result without attempting the actual merge, which is
useful in some of my scripts.

OK. I guess we can live with the series I posted earlier (to simplify
the add/add behavior and fix the overflow), and leave it in place.

I _do_ think it's a useful concept, and there isn't something quite like
it in git right now. At one point I contemplated teaching unpack-trees
to do the content-level merges too, so you could do this via read-tree,
but I didn't ever polish it[1]. So I am sympathetic to the goal, and
there's not another way to do it as efficiently.

And now I feel like both of you have been warned that the code might be
crufty. :)

I'm not sure what we should do about warning others.  Since people are
using it, I don't want to put a deprecation warning. It's not "this will
be removed in the next version" anymore, but "watch out, this might be
crufty". I guess that can go in the manpage, but I'm not quite sure how
to word it.

-Peff

[1] It looks like my patch has been collecting dust since 2011:

      git://github.com/peff/git.git jk/read-tree-content-merge-wip

    It's been rebased along with all of my other topics since then, but
    otherwise I have no clue if it works or even compiles (it's not part
    of my day-to-day build). Anyone is welcome to use it as a base if
    they want to pursue it.