Jeff King <peff@xxxxxxxx> writes: > On Tue, Oct 07, 2008 at 07:52:02AM +0200, Johannes Sixt wrote: > >> How about this: If I run 'git show -- foo.doc' (foo.doc resolves to a >> single path, obviously), I want MS Word, but for other uses of 'git show' >> I don't. I think that heuristics could be very effective: With a plain >> 'git show' I get the overview of the change, and with 'git show -- >> foo.doc' I drill down into a single document. > > Hrm. I am not opposed to heuristics, but in this case, I don't like the > one you have proposed. ;P > > My specific case that prompted this work is a repository full of > pictures and videos, where I rarely (if ever) change the media content, > but frequently change exif tags. So my "usual" case is to want to see > "git log -p" with the textconv'd version. The commit diffs are otherwise > totally meaningless. So, you disagree about "git log" not showing the textconv, but you still agree with half of the proposal :-P. When the user explicitely requests a single file, he does want textconv (requesting a diff for a single file and be happy with "binary files differ" would be strange ...). It seems quite clear to me that we won't get a heuristic right for everybody (some diff driver are fast, some are slow, some require an external GUI, some don't, ...). Better let the thing be nicely configurable IMHO. One proposal: have a diff.<driver>.activate with several values: * "always": activate the diff driver in any porcelain * "diff": activate it only for "git diff", as currently * "singlefile": Johannes's heuristic proposal That way, one could say easily "activate exiftags filter all the time, but MS-Word only when I request a diff for a single file", and this leaves room for other values if the need be. Well, there's no room for "use MS-Word native diff tool in git-gui but antiword/catdoc + textconv in 'git log -p'" here, but do we want it? Or is all that just overkill? -- Matthieu -- 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
