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

Junio C Hamano [off-list ref] writes:

Johannes Sixt [off-list ref] writes:

quoted

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

Well explained.

"-p" in general is an instruction to show some form of textual
patch, and "--cc" and "-c" are the variants (i.e. compare with each
parent and combine the comparison results) of it that naturally
degenerates to the normal patch output when there is only one
parent.

"--cc" also flips the "m" bit,  which controls if there is any tree
comparison should be made for merge commits, which matters for "log"
family of commands, so in that sense "--cc" was made to imply "-m",
but "--cc" inherently means "-p" for non-merge commits without any
need to say X implies Y.

Except both Git documentation and implementation are in some
contradiction with the explanations above, as far as I can see, so this
looks to me like a kind of wishful thinking, sorry.

[One can read, say, year old Git documentation, prior to recent patches
(to get rid of possible bias), to see that it describes different
picture and explicitly contradicts some of the statements above, and
then I definitely did no steps to move in the direction described above
either, at least intentionally.]

Anyway, here is the current reality the way I see it (this description
assumes "-m imply -p" patch by me has been reverted due to introduction
of slight backward incompatibility):

-p enables diff for non-merge commits only
--diff-merges=XXXX enables diff for merge commits only

--cc => -p --diff-merges=cc
-c   => -p --diff-merges=c
-m   =>    --diff-merges=m

where "=>" means "is shortcut for".

Simple and clear, except -m is an outlier, as it does not imply -p.
Further, -m produces inconvenient output unless --first-parent is also
in use, and then --first-parent already implies -m, rendering explicit
-m virtually useless.

Due to this outlier, all the recent changes in this area were targeted
to make -m useful, similar to --cc/-c, not to change --cc/-c, or -p
semantics at all, so that finally we get perfect:

--cc => -p --diff-merges=cc
-c   => -p --diff-merges=c
-m   => -p --diff-merges=m

Please also notice that with this system there is no need for every
(new) way of representing of merge commits to support "fall back to -p
in case of non-merge commits" at options level, as it does not have to
deal with non-merge commits at all.

Thanks,
-- Sergey Organov