First of all: Jeff, thanks a bunch for taking this up again! That's a great improvement. (I'm not sure I can devote enough time to reviewing, but I'll see.) Junio C Hamano venit, vidit, dixit 24.05.2011 06:46: > Jeff King <peff@xxxxxxxx> writes: > >>> However, custom diff drivers (still) don't work. :-) >> >> Yeah, I didn't add any support for that. I'm not sure what it should do; >> custom diff drivers don't know how to handle combined diff, do they? >> >> If you write me a test case that explains what _should_ happen, I'll see >> what I can do. :) > > I do not think it is sensible to expect anybody to come up with a sane > semantics for combined diff to work with GIT_EXTERNAL_DIFF (and external > diff driver that can be specified via the attributes mechanism) in any > meaningful way. > > The whole point of the external diff mechanism is that an external command > can take _two_ files and represent the change between them in a way that > is more suited for the need of the user than the patch form. The output > from such an external command does not have any obligation to even follow > the convention used by the patch output, namely: > > @@ from here to there things have changed @@ > this is common > -this was the removed content > +this is the new content > > as the _whole_ point of the external diff mechanism is to give something > that is _different_ from the patch form, in the hope that it is in a more > appropriate form for whoever consumes the output. > > On the other hand, combined diff is all about combining multiple patches > show them side-by-side in a combined fashion. Without the above four kinds > of cues, there is no way to even _align_ the change outputs from two > parents, let alone _combining_ them. > > Anybody interested can check "compare-cooking.perl" in the todo branch, > which is used as an external diff driver to view the differences between > "What's cooking" postings via these: > > [diff "whatscooking"] > xfuncname = "^\\[(.*)\\]$" > command = ./compare-cooking.perl > > in the .git/config file, together with > > whats-cooking.txt diff=whatscooking > > in the .gitattributes file. Running > > $ git log -p --ext-diff todo -- whats-cooking.txt > > would give a sample output. > > 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. When the --cc/textconv issue came up I looked into this, and maybe difftool is a place where one could plug this in first in the sense of refactoring that even more and providing a diff3tool or such to view a merge commit (or compare any 3 versions), or/and provide "git diff3 A B C" which creates a fake merge (A+B -> C). Now, imagine we also have INDEX and WORKTREE pseudorevs and can do git diff3[tool] HEAD INDEX WORKTREE :) Michael -- 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