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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html