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

Sergey Organov [off-list ref] writes:

quoted

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?

If we are primarily interested in theoretical completeness, it may.
If we are interested more in practical usefulness, I am not sure if
such a "full flexibility" matrix is a good way to present the
feature to the end-users.