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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 7, 2020, 19:46 UTC
Message-ID: <xmqq8seqgrx3.fsf@gitster.c.googlers.com>
In-Reply-To: <87tuxel17m.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 21 quoted lines

>>> 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.
>
> I thought it's just a -c, -cc, and -m in better wording. No any
> matrix:
>
> -c  = --diff-merges=combined
> -cc = --diff-merges=dense
> -m  = --diff-merges=split
>
> Just separate mutually exclusive options assembled into one multi-value
> option, so it's explicit they are mutually exclusive. I don't see any
> matrix here.

Oh, matrix comes from specifying the set of parents in a separate parameter. If we are not doing that, then you cannot even express "when showing a merge, compare only with the first parent", no?

And when you add --diff-parents=1 (i.e. diff with first-parent), you are opening the interface up so that it can express dubious combinations like --diff-merges=dense-combined --diff-parents=1,3 (i.e. --cc but exclude the second parent as one of the preimages).

You also have a redundant combination, e.g.

    --diff-merges=(off,combined,dense-combined,each) --diff-parents=""

would be the same as --diff-merges=off without saying which parents to compare with.