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