Johannes Sixt [off-list ref] writes:
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.
Thanks.