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

From: Sergey Organov <[email-masked]>
Date: Fri, 07 Aug 2020 20:52:00 +0300

Junio C Hamano <[email-masked]> writes:

> Jeff King <[email-masked]> 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...

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