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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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...