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

[Sergey Organov <sorganov@gmail.com>]

Johannes Sixt <j6t@kdbg.org> writes:

> Am 08.09.21 um 15:43 schrieb Sergey Organov:
>> Besides, nobody yet told us why gitk uses --cc option in invocation of
>> 'diff-index' in the first place. Does it actually *rely* on particular
>> undocumented behavior of "diff-index --cc", or is it just a copy-paste
>> *leftover*?
>
> No, it is not a left-over. The thing is,
>
> - there is one point in the code where gitk adds options -p -C --cc (and
> more) to the command line (around line 8034),
>
> - and there is a totally different point in the code where it is decided
> whether diff-index, diff-tree, or diff-files is invoked (proc diffcmd
> around line 7871).
>
> IOW, Gitk expects that these option combinations can always be passed to
> all three commands.

I see, but the problem here is that while diff-files and diff-tree both
accept --cc according to their documentation, diff-index does not. This
means that, strictly speaking, gitk makes a mistake treating all 3
commands universally with respect to command-line arguments when it uses
--cc.

>
> Gitk does not want to look at a commit and then decide which incarnation
> of the command it wants to use (--cc vs. -p) depending on whether it is
> a merge commit or not. This decision is delegated to command that is
> invoked.

The problem is not in the kind of commit, the problem is in the command
being invoked. diff-index doesn't support --cc according to its
documentation, and thus gitk relies on undocumented behavior of
diff-index. It might well be the case that it just happened to be
"working", thus nobody cared.

> Therefore, silent fall-back from --cc to -p in case of non-merge
> commits or non-conflicted index is absolutely necessary.

I didn't change semantics of --cc, so this thing was not broken at all.
I just disabled the --cc option in diff-index command, to match the
documentation.

As a side note, in fact Git does no "silent fall-back from --cc to -p in
case of non-merge commits", even though the behavior could be indeed
seen like this. Instead, --cc implies -p, and, as --cc does not
otherwise affect treating of non-merge commits, only -p is left active
for them. Once again, this has not been recently changed, so does not
need to be fixed.

Thanks,
-- Sergey Organov