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