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

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