Sergey Organov <sorganov@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> 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.
