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

[Jeff King <peff@peff.net>]

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

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