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

From: Sergey Organov <[email-masked]>
Date: Mon, 30 Aug 2021 20:40:27 +0300

Junio C Hamano <[email-masked]> writes:

> Johannes Sixt <[email-masked]> 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.

I'm pretty sure I've checked diff-index doesn't use the flag that --cc
sets when I wrote the patch, so the only incompatibility this patch
introduced is denying the command when --cc is given, i.e., it now
behaves as if diff-index doesn't support --cc *option*, that makes sense
to me and matches diff-index documentation.

Irrespective to chosen solution, it still looks to me like gitk
shouldn't had --cc in that command in the first place. I that correct,
or do I miss something essential?

That said, if you think that diff-index should silently accept --cc (and
-c ?), for whatever reason, it's fine with me, provided it's properly
documented and there are proper test-cases in place.

Thanks,
-- Sergey Organov