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