Jeff King <peff@xxxxxxxx> 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...
