Thread (1 message) 1 message, 1 author, 2020-08-03

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help