Re: Why doesn't `git log -m` imply `-p`?

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2021, 01:15 UTC
Message-ID: <xmqqtunj70zy.fsf@gitster.g>
In-Reply-To: <87czu7u32v.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

>>  * "--patch", "--stat", "--cc" etc are to specify if we use the diff
>>    machinery and what kind of output is desired.
>
> So, in your view, --cc output is not a product of "diff machinery"?

I view --cc and -c as an enhanced form of --patch that is also capable of handling multi-way diffs, in other words, choosing --cc should be to say "give me textual patch for all commits; when there are multiple parents, condense multi-way patches".

So, yes, strictly speaking, --diff-merges=cc was probably a mistake, and in the ideal world, --diff-merges should have taken only one of "compare with nothing" (optional), "compare with first-parent", and "compare with all parents". The last choice could output diffs in various forms, like traditional -m (i.e. patch output separately for each parent), --cc, -c, etc. "compare with nothing" is optional because we could also control on the "output format" side to say "produce no output" (ala "git show -s").

But such an idealized orthogonal design without special casing will often lead to usability problems and complaints that -m alone does not produce anything, so I am OK to have cc and friends as the value for --diff-merges for that reason.