Re: [PATCH v2 0/7] making log --first-parent imply -m

Junio C Hamano [off-list ref] writes:

Jeff King [off-list ref] writes:

quoted

Agreed. My only question is whether the possibility of later having
those other options might influence how we name the two options we add
now. I think it's clear to all of us in this thread how those two easy
options should behave, but if the intent is to eventually allow these to
be mutually exclusive:

  - no diff
  - combined
  - dense combined
  - individual diff against each parent

but orthogonal to the selection of the parent-set (none, all, or
selected ones) then e.g. "all" makes less sense for "individual diff
against each parent". I don't have a good succinct name suggestion,
though.

TBH, I would be happy enough with any of the suggestions in the thread,
so I am really just finishing the thought here, and not trying to derail
progress. :)

I agree in principle that the above is a good framework to think
about the issue around "what to do with diff when showing a merge
commit", but I suspect that overly spending our effort to cover the
possibilities become mostly useless mental exercise, mostly because
(1) comparing with second parent is mostly useful only when the
merge was done in the wrong direction (i.e. an attempt by a leaf
contributor to "catch up to the trunc"), (2) octopus merges are rare
curiosity and discouraged due to bisect efficiency anyway, and (3)
even when looking at an octopus merge, omitting some and using only
a few selected parents to view with --cc/-c has dubious usefulness,
as the postimage has to show contributions from all the parents
plus "evil" adjustment anyway (iow, the primary effect of omitting
parents while viewing --cc/-c is to make it fuzzy which part of
apparently "evil" adjustment is what the merge did vs what the
hidden parents did).  These are all examples that show not all the
combinations are useful.

So...

So, does

--diff-merges=(off,none|comb|dense,dense-comb,comb-dense|sep,split)

make sense as covering all the current features?

I've put variations that came to my mind. Probably we'd better just select
one for each case.

Thanks,
-- Sergey