Vadim Zeitlin [off-list ref] 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.
On Thu, 10 Mar 2016 14:33:55 -0800 Junio C Hamano [off-list ref] wrote:
JCH> Vadim Zeitlin [off-list ref] 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