Re: diff-index --cc no longer permitted, gitk is now broken (slightly)

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Johannes Sixt <j6t@kdbg.org> 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.

If the patch breaks essential (even if undocumented and untested)
behavior, as Jeff pointed, it should obviously be fixed. I'll look at it
more closely to suggest a fix.

Thanks,
-- Sergey Organov