Re: combined diff does not detect binary files and ignores -diff attribute

On Wed, May 25, 2011 at 09:38:43AM +0200, Michael J Gruber wrote:

quoted

I agree with Junio that we would need a new config option and external
interface for "n-way combined diff". However, isn't what things like
vimdiff and meld do the reverse of our combined diff? That is, don't
they assume the 3 trees are: ours, theirs, and ancestor (i.e., merge
base)? Whereas in a combined diff, it is actually: merge parent 1
(ours), merge parent 2 (theirs), and merge _result_.

Also, do those tools generally handle n-way comparisons as opposed to
3-way?

"Those" tools do "that" which I mean :)

OK, they are more capable than I realized, then. :)

So, in vimdiff, you could in principle change and write any buffer but
our tools don't support it so far because it is not needed for a merge
which has one "target" only. In the ui of my dreams, I would have 3
buffers HEAD INDEX WORKTREE (H I W) and moving hunks between them would
do all of add -p, reset -p and checkout -p (the HEAD buf would be
read-only).

This should be relatively easy to implement on the git side, as you are
doing the hard parts of the "-p" operation in vim already. You just need
to write vim's buffer into the worktree or into the index via
hash-object / update-index.

Also, wouldn't you potentially want more than 3 buffers, if you were
cherry-picking changes from another commit (as in "git checkout -p
$commit" or even putting and taking things from a stash? I think that
would be a simple generalization of what you are proposing though.

With "differently abled" tools it could still be useful to have, say a
tool invoked for the merge HEAD+WORKTREE -> INDEX (with the current
state of the INDEX as the automatic resolution to start off from) so
that you can do add+reset -p with your mergetool, and maybe similarly
for HEAD+INDEX -> WORKTREE. I.e. addtool and checkouttool in addition to
the difftool and mergetool which we have. Just not for the current
release cycle any more.

Yeah, getting back to the original discussion. How badly do people
actually want an external diff driver that can do fancy things with
multiple parents? It seems that for non-text diff viewers, the preferred
solution is to use difftool these days (but that is just my impression;
I don't use either difftool or external diff drivers).

-Peff