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

[Jeff King <peff@peff.net>]

On Tue, May 24, 2011 at 09:19:43AM +0200, Michael J Gruber wrote:

> > It is conceivable that we _could_ newly define a "combined external diff
> > driver" that would take 3 or more files, and compute and show the combined
> > result by itself, but that will certainly not go through the codepath you
> > touched with the textconv patch. Calling out to such a new type of
> > external diff driver would have to happen at the level where we have 1+N
> > blob object names for a N-parent commit, namely, at the beginning of
> > show_patch_diff(), bypassing the entire contents of that function and
> > instead letting the new n-way external diff driver do everything.
> > 
> > I however highly doubt that such an interface would make sense. For
> > example, what would be the desirable format to compare three versions of
> > "What's cooking" postings, and how would the updated compare-cooking.perl
> > script would look like?
> 
> Yeah, currently --cc with external makes no sense, but there are several
> external tools which could present a 3-way diff in a useful way (or even
> n-way with n>3), e.g. vimdiff, kdiff3, meld.

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?

-Peff