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. 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
