Re: Possible bug: --ext-diff ignored with --cc in git log
On Fri, Mar 11, 2016 at 11:08:32AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> It happens that the above is fairly easily doable with today's Git > >> without any modification. Here is how. > >> [...] > > > > I think an even easier way is: > > > > git log --cc --raw > > > > I know that is somewhat beside the point you are making, which is how we > > should handle "--cc" with ext-diff. But I would much rather have us > > show nothing for that case, and let the user turn on "--raw", than to > > invent a diff-looking format that does not actually represent the file > > contents. > > Sorry, but I am not sure where you are trying to go with this. > > I understand that the original issue was that Vadim wants to > suppress reams of differences for _some_ paths but still wants to > benefit from the textual summarized diff for all the other paths. > Giving "--raw" would be global, and would affect other paths, no? Ah, sorry, I thought the problem was the opposite: that there was no output for ext-diff paths, and we needed to add something back in. Doing "--raw" is a much easier way than textconv of the "add back in" part, but it does not suppress the ordinary combined diff. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug: --ext-diff ignored with --cc in git log
Jeff King writes: >> It happens that the above is fairly easily doable with today's Git >> without any modification. Here is how. >> [...] > > I think an even easier way is: > > git log --cc --raw > > I know that is somewhat beside the point you are making, which is how we > should handle "--cc" with ext-diff. But I would much rather have us > show nothing for that case, and let the user turn on "--raw", than to > invent a diff-looking format that does not actually represent the file > contents. Sorry, but I am not sure where you are trying to go with this. I understand that the original issue was that Vadim wants to suppress reams of differences for _some_ paths but still wants to benefit from the textual summarized diff for all the other paths. Giving "--raw" would be global, and would affect other paths, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug: --ext-diff ignored with --cc in git log
On Fri, Mar 11, 2016 at 10:20:42AM -0800, Junio C Hamano wrote: > diff --cc foo.sln > index d7ff46e,6c9aaa1..b829410 > --- a/foo.sln > +++ b/foo.sln > @@@ 1,1 @@@ > - d7ff46ec4a016c6ab7d233b9d4a196ecde623528 - generated file > -6c9aaa1ae63a2255a215c1287e38e75fcc5fc5d3 - generated file > ++b829410f6da0afc14353b4621d2fdf874181a9f7 - generated file > > which would at least tell you that there was a merge, and if the > merge took the full contents of the file from one of the commits and > recorded as the result of the merge, then you wouldn't see them in > the "--cc" output. > > It happens that the above is fairly easily doable with today's Git > without any modification. Here is how. > [...] I think an even easier way is: git log --cc --raw I know that is somewhat beside the point you are making, which is how we should handle "--cc" with ext-diff. But I would much rather have us show nothing for that case, and let the user turn on "--raw", than to invent a diff-looking format that does not actually represent the file contents. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug: --ext-diff ignored with --cc in git log
Vadim Zeitlin writes: > On Thu, 10 Mar 2016 14:33:55 -0800 Junio C Hamano wrote: > > JCH> Vadim Zeitlin writes: > JCH> > JCH> > I.e. the > JCH> > command "git log --ext-diff -p --cc" still outputs the real diff even > for > JCH> > the generated files, as if "--ext-diff" were not given. ... > JCH> > Is the current behaviour intentional? I see it with all the git > versions I > JCH> > tried (1.7.10, 2.1.0, 2.7.0 and v2.8.0-rc1), but I don't really see why > JCH> > would it need to work like this, so I hope it's an oversight and could > be > JCH> > corrected. > JCH> > JCH> I think this is "intentional" in the sense that "--cc" feature is > JCH> fundamentally and conceptually incompatible with "--ext-diff". > > Thank you for your reply, Junio, I hadn't realized that --cc was dependent > on textual diff output format before, but now I understand why it can't > respect --ext-diff. Having established that, I should also add that "--cc fundamentally is incompatible with --ext-diff" does not justify that "--cc when given with --ext-diff just ignores and uses the usual diff". An equally (or even more) valid consequence could have been to disable "--cc" processing for paths that would trigger an external diff driver. After all, the user told us that the contents would not compare well with the usual "diff"; we know that "--cc" output that summarizes the usual diff output is useless. What we show instead is an interesting thing to think about. For example, we _could_ also ignore what external diff driver produces in this case (as we know it won't be producing an appropriate input to the "--cc" post-processing), and pretend as if comparing an old version of foo.sln with a new version of foo.sln produced a diff like this: diff --git a/foo.sln b/foo.sln index d7ff46e,b829410 --- a/foo.sln +++ b/foo.sln @@ 1,1 @@ -d7ff46ec4a016c6ab7d233b9d4a196ecde623528 - generated file +b829410f6da0afc14353b4621d2fdf874181a9f7 - generated file then you might see in a merge that merges two versions of foo.sln and result in another version of foo.sln in your "--cc" output a hunk that is like this: diff --cc foo.sln index d7ff46e,6c9aaa1..b829410 --- a/foo.sln +++ b/foo.sln @@@ 1,1 @@@ - d7ff46ec4a016c6ab7d233b9d4a196ecde623528 - generated file -6c9aaa1ae63a2255a215c1287e38e75fcc5fc5d3 - generated file ++b829410f6da0afc14353b4621d2fdf874181a9f7 - generated file which would at least tell you that there was a merge, and if the merge took the full contents of the file from one of the commits and recorded as the result of the merge, then you wouldn't see them in the "--cc" output. It happens that the above is fairly easily doable with today's Git without any modification. Here is how. (1) Have this in your .git/config [diff "uninteresting"] textconv = /path/to/uninteresting-textconv-script (2) Mark your .sln paths as uninteresting in your .gitattributes *.sln diff=uninteresting (3) Have this textconv filter in /path/to/uninteresting-textconv-script #!/bin/sh printf "%s generated file\n" "$(sha1sum <"$1")" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug: --ext-diff ignored with --cc in git log
Vadim Zeitlin writes: > I.e. the > command "git log --ext-diff -p --cc" still outputs the real diff even for > the generated files, as if "--ext-diff" were not given. ... > Is the current behaviour intentional? I see it with all the git versions I > tried (1.7.10, 2.1.0, 2.7.0 and v2.8.0-rc1), but I don't really see why > would it need to work like this, so I hope it's an oversight and could be > corrected. I think this is "intentional" in the sense that "--cc" feature is fundamentally and conceptually incompatible with "--ext-diff". - The "external diff" feature is to allow third-party tools to produce output that is vastly different from the usual "diff" output, e.g. unlike the usual "diff", the output may not even be line-oriented, and certainly would not have to follow the convention of denoting the contents on old and new lines with "-" and "+" prefixes. - The "--cc" feature is to show multiple "diff" outputs in the usual format with post-processing to coalesce them into a more concise form, and fundamentally depends on (1) the output being line-oriented and (2) the contents of old and new lines denoted by "-"/"+" prefixes to be able to do so. I haven't tried it myself, but if the contents you are using ext-diff on can be compared in a format that is easy-to-read for humans by passing them first to "textconv" filter and then running the normal "diff" on, that may be a viable approach to do what you are trying to do, as "textconv" feature is meant to still produce the output that still follows the usual "diff" convention. Its output should be usable by any tool (e.g. diffstat) meant to post-process patch output, and would be a better match for the "--cc" mechanism. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
