Jeff King <peff@xxxxxxxx> writes: > On Mon, Aug 03, 2020 at 06:47:20PM +0300, Sergey Organov wrote: > >> > A command line option that takes _optional_ argument is evil; it >> > hurts teachability (e.g. "why does this option always require >> > "--opt=val" and refuses '--opt val'?"). >> >> Yeah, I sympathize. > > Sorry, the optional argument was my suggestion. I don't think they're > that evil, but I agree they require extra knowledge for the user. I > don't mind avoiding them when possible (and it's definitely possible > here). > >> > Introduce --diff-parent=(none|<parent-number>|c|cc|all) that is >> > different from --diff-merges, and -m and --[no-]diff-merges can be >> > defined in terms of that, at which point we can gradually deprecate >> > them if we wanted to, no? >> >> Sounds great, I only hoped we can do it right now, with this new >> --diff-merges option, maybe as a pre-requisite to the patches in >> question, but Jeff said it's too late, dunno why. > > 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? > 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. Thanks, -- Sergey
