Jeff King <peff@xxxxxxxx> writes: > On Mon, Aug 03, 2020 at 11:00:11PM +0300, Sergey Organov wrote: > >> > It's too late for "-m" to change semantics (we could do a long >> > deprecation, but I don't see much point in doing so). >> >> I thought not of changing semantics of -m. Suppose we introduce >> >> --diff-merges=(none|<parent-number>|c|cc|all) >> >> before your patch(es). Then your patch would read: "making --first-parent >> imply --diff-merges=1" and it'd miss that --[no-]diff-merges part, no? > > Sure, that would be OK with me. You'd have --diff-merges=none to get > the current behavior, and probably make --no-diff-merges an alias for > that. Yes, keeping --no-diff-merges as an alias might make sense, especially if it's on top of yours. > >> > But --diff-merges is definitely still changeable until we release >> > v2.29. My resistance was mostly that I didn't want to complicate my >> > series by adding new elements. But we could do something on top. >> >> Can't we do yours on top instead? I'd expect it'd then be even simpler. > > Mine is in 'next', so there is no rebuilding it on top of anything else > without a revert. But I don't see any particular reason to do that > versus just changing the behavior on top. What's in 'next' is generally > not rewound, but the behaviors are not cemented with respect to > backwards compatibility. Ah, now I see, thanks! -- Sergey
