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

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

quoted

 * "--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