Re: combined diff does not detect binary files and ignores -diff attribute
- From
Jeff King <peff@peff.net>
- Date
- May 24, 2011, 19:13 UTC
- Message-ID
- <20110524191337.GB584@sigill.intra.peff.net>
- In-Reply-To
- <4DDB5C0F.1080102@drmicha.warpmail.net>
On Tue, May 24, 2011 at 09:19:43AM +0200, Michael J Gruber wrote:
Show 17 quoted lines
> > 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