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

Johannes Sixt [off-list ref] writes:

Am 08.09.21 um 15:43 schrieb Sergey Organov:

quoted

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