Duy Nguyen <pclouds@xxxxxxxxx> writes:
> I don't know the scope of these microprojects, but yes I think it'll
> take a few hours for this. By the way, a bit more thought on the idea:
> instead of making OPT_BOOL_NONEG() that sets NONEG, we could make
> OPT_BOOL_FLAGS(..., NONEG), which is more flexible.
What does a boolean that can never be set to false achieve, by the
way? If you have
[alias]
foo = bar --frotz
then you may want to be able to say "git foo --no-frotz" to
countermand the frotz option, and by marking the boolean frotz
option to be a NONEG, you can forbid such a usage. That is the only
"use case" I can think of, and that particular use case does not
sound like a valid one.
Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is
associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the
existing code.
Perhaps OPT_SET_INT should default to not just OPT_NOARG but also
OPT_NONEG?
I have a suspition that most users of other OPT_SET_<TYPE>
short-hands may also want them to default to NONEG (and the rare
ones that want to allow "--no-value-of-this-type=Heh" for some
reason to use the fully spelled form). IIRC NONEG is relatively a
new addition, and many existing OPT_STRING() may predate it.
So I am not sure if doubling the number of OPT_<type> macros as your
micro suggestion proposes is the right solution to the problem.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html