Thread (2 messages) flat view 2 messages, 2 authors, 2020-08-04

Re: [PATCH v2 0/7] making log --first-parent imply -m

From: Junio C Hamano <hidden>
Date: 2020-08-04 19:42:53

Sergey Organov [off-list ref] writes:
Jeff King [off-list ref] writes:
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). 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.
Attached is rather minimal incompatible change to --diff-merges that'd
allow extensions in the future, to get out of urge for the discussed
changes. I'm going to follow-up with actual improvements and I'm aware
it lacks documentation changes.
The overall direction is probably OK, but I wouldn't call it minimal.
What do you think, is it OK to have something like this before v2.29?
And, by the way, what's approximate timeline to v2.29?
tinyurl.com/gitCal
As for me, I'm not sure 'combined-all-paths' should be included and if
it should, is it a good enough name.
As a user, I do not think I can guess, from the option name, what
that option is trying to do.

As a minimum patch, I think it is OK to have just 'all' and 'none'
(not even c or cc, let alone the one with ultra-long name whose
effect is mystery) before we let the result graduate to 'master'.
Others can be added on top, as the primary focus of Peff's series is
to make sure "-m" can be countermanded, for which being able to say
"no" is sufficient, and the primary reason why we are further
futzing with the series with this addition is to leave the door open
for later additions of different "modes" in which how
"--diff-merges" option can operate (iow, Peff's was merely on/off,
but you are making sure others such as <num> can be added over
time).

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help