Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. 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
