Jeff King <peff@xxxxxxxx> writes:
> We cannot simply add 0/1 support to git_config_maybe_bool.
> That would confuse git_config_bool_or_int, which may want to
> distinguish the integer values "0" and "1" from bools.
... e.g. number one spelled as "1" do mean one not true in contexts like
status.submodulesummary, where "true" means "unlimited" and "1" means
"limit to one". It surely is necessary to avoid breakage there.
A caller that uses git_config_maybe_bool() expects to see 0/1 when the
input looks like a boolean, and your patch looks like the right thing to
do.
The repertoire of parsers that involve elements that are possibly boolean
are now:
- git_config_bool(): takes "0/false/no/..." or "$n/true/yes/..." (where
any non-zero number $n is taken as true [*1*]), or more traditional
[section]
var
without any equal sign, which means true. Errors out if the input is
not a boolean.
- git_config_maybe_bool(): similar, and returns -1 (not a bool), 0
(false) and 1 (true). "0" is false, "1" is true. But all other
numbers are not boolean;
- git_config_bool_or_int(): the caller can tell if the value was boolean.
"0" and "1" are integers, and not boolean. Errors out if the input is
not bool nor int.
Perhaps we would want to add Documentation/technical/api-config.txt
someday? Hint, hint....
[Footnote]
*1* I doubt anybody is insane enough to have an existing configuration
file that spells "true" with "2" (or "100"), so it might be ok to tighten
the rule after the fact a bit here to take only "1" as true from purist's
point of view, but I do not think the upside outweighs possible breakage.
--
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