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

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>>> 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.

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.

Thanks,
-- Sergey