Johannes Sixt <j6t@xxxxxxxx> 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
