Re: Possible bug: --ext-diff ignored with --cc in git log

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2016, 18:20 UTC
Message-ID: <xmqqziu4anb9.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <E1aeCRp-0005Jn-C1@smtp.tt-solutions.com>

Vadim Zeitlin <vz-git@zeitlins.org> writes:

Show 18 quoted lines

> On Thu, 10 Mar 2016 14:33:55 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>
> JCH> Vadim Zeitlin <vz-git@zeitlins.org> 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")"