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

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.

JCH> I haven't tried it myself, but if the contents you are using JCH> ext-diff on can be compared in a format that is easy-to-read for JCH> humans by passing them first to "textconv" filter and then running JCH> the normal "diff" on, that may be a viable approach to do what you JCH> are trying to do, as "textconv" feature is meant to still produce JCH> the output that still follows the usual "diff" convention. Its JCH> output should be usable by any tool (e.g. diffstat) meant to JCH> post-process patch output, and would be a better match for the JCH> "--cc" mechanism.

 I can't think of a way to make the output as concise as it is now (i.e.
just a single line saying that a generated file has been modified but the
changes to it are not being shown) with this approach.

 Maybe I'm clutching at straws here, but I wonder if it could be possible
to have a file attribute specifying whether --cc or -m should be used for
it when showing merges? Because this is, basically, what I want here: --cc
for normal files for readability but -m for the files I'm not interested
in. It's probably too specific to my particular hack^H^H^H^H use case to
add support for it to Git itself, but I wanted to mention it on a chance
that somebody else might think it's a good idea.

 Anyhow, thanks again for your explanation,
VZ