Re: [PATCH v2 0/7] making log --first-parent imply -m
From: Sergey Organov <hidden>
Date: 2020-08-03 21:19:02
Jeff King [off-list ref] writes:
On Mon, Aug 03, 2020 at 11:00:11PM +0300, Sergey Organov wrote:quoted
quoted
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.
quoted
quoted
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