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

From: Sergey Organov <[email-masked]>
Date: Tue, 04 May 2021 12:10:55 +0300

Junio C Hamano <[email-masked]> writes:

> Sergey Organov <[email-masked]> 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.

I basically agree with what you say here, and it's in fact very close to
the first variant of the design that originally came to my mind, and it
was reality that shifted things to the way they are implemented now.

That said, what do we decide about -m to finally join -c/--cc party and
start to imply -p? Last time we've discussed it, we decided that -m has
been simply overlooked when -c/--cc started to imply -p. Should we
finally fix this?

Thanks,

-- Sergey Organov