Junio C Hamano <gitster@xxxxxxxxx> writes:
> Johannes Sixt <j6t@xxxxxxxx> writes:
>
>> Since 19b2517f95a0 (diff-merges: move specific diff-index "-m" handling
>> to diff-index, 2021-05-21) git diff-index no longer accepts --cc. This
>> breaks gitk: it invokes
>>
>> git diff-index --cached -p -C --cc --no-commit-id -U3 HEAD
>>
>> to show the staged changes (when the line "Local changes checked in to
>> index but not committed" is selected).
>>
>> The man page of git diff-index does not mention --cc as an option. I
>> haven't fully grokked the meaning of --cc, so I cannot tell whether this
>> absence has any significance (is deliberate or an omission).
>>
>> Is gitk wrong to add --cc unconditionally? Should it do so only when
>> there are conflicts? Or not at all?
>
> I think --cc is designed to naturally fall back to -p when there is
> only one parent. Use of both -p and --cc has also long been an
> acceptable combination, and even if we say the later --cc overrides
> -p, there is no reason not to show single parent patch here with
> --cc.
Another tangent.
I think the use of --cc with diff-index can make sense in another
way.
$ echo "# both" >>COPYING
$ git add COPYING
$ echo "# work" >>COPYING
Now we have one extra line at the end in both the index and the
working tree file, with yet another at the end of the latter.
$ git diff-index --cc HEAD
is a way to show combined diff to go to the working tree version
starting from HEAD and starting from the index (I needed to use an
old version because the 'maint' and upwards are broken as reported).
$ rungit v1.5.3 diff-index --cc HEAD
diff --cc COPYING
index 8b9c100,536e555..0000000
--- a/COPYING
+++ b/COPYING
@@@ -358,4 -358,3 +358,5 @@@ proprietary programs. If your program
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.
+# both
++# work
Now the way "gitk" used is with "--cached", so there is no multi-way
comparisons to be combined, and it is natural to fall back to "-p",
so it is a different issue, but since we invented "--cc" to
originally emulate, and to later improve, the output from gitk,
I am reasonably sure that its use of "--cc" should be supported.
