Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >>>> 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). I had no intention to introduce --diff-parents, at least for now, and maybe never. What I said about it was theoretical discussion rather than actual proposal. If we agree on the above, I intended to instead propose something like: --diff-merges=first-parent or just =first for a start. Thanks, -- Sergey
