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. > > 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. -Peff
