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.
