On Wed, Feb 24, 2016 at 08:28:59AM +0100, Dennis Kaarsemaker wrote:
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html