Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> 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
