Am 24.07.23 um 20:51 schrieb Junio C Hamano: > René Scharfe <l.s.r@xxxxxx> writes: > >> Am 21.07.23 um 22:09 schrieb Junio C Hamano: >>> René Scharfe <l.s.r@xxxxxx> writes: >>> >>>> - -D, --no-doubt begins with 'no-' >>>> + -D, --[no-]no-doubt begins with 'no-' >>> >>> Hmph, I really really loved the neat trick to allow "no-doubt" >>> option to be "positivised" by _dropping_ the leading "no-" at around >>> 0f1930c5 (parse-options: allow positivation of options starting, >>> with no-, 2012-02-25). >> >> Yeah, if there is a better way to document A) that the "no-" is optional >> and B) whether it's present by default, I'm all ears. > > Some options take "no-" prefix while some others do not, so > indicating that "this can take negative forms" vs "this do not take > negative forms" by "--[no-]xyzzy" and "--frotz" makes sense. > > Yikes. There are tons of options whose names begin with "no-" and > marked PARSE_OPT_NONEG, so "an option '--no-nitfol' that does not > have the 'no-' part in [brackets] can drop 'no-' to make it > positive" would not fly as a rule/convention. > > If we do not mind getting longer, we could say > > -D, --no-doubt, --doubt > > and explain in the description that --no-doubt is the same as -D and > --doubt is the default. It is making the developers responsible for > clarify, which is not very satisfying. Adjusting all explanations manually seems quite tedious. > We may not reject "--no-no-doubt" but with the positivization > support, double negation is not something we'd encourage without > feeling embarrassed. Right. Perhaps --[[no-]no-]doubt? Looks a bit silly with its nested brackets, but it's more correct, because it documents all three accepted forms, including the no-less one. René
