Martin Ågren <martin.agren@xxxxxxxxx> writes: > With `--type=bool`, we try to canonicalize the "value_regex". If it > doesn't canonicalize, we continue and handle the "value_regex" as an > ordinary regex. This is deliberate -- we do not want to cause existing > scripts to fail. > > This does mean that users might be at risk of missing out on config > values depending on which representation they use in their config file: > > $ git config foo.bar on > $ git config foo.baz true > $ git config --type=bool --get-regex "foo\.*" tru > foo.baz true > $ # oops! missing foo.bar > > Let's start warning when the "value_regex" doesn't look like a boolean. > Document our intention of eventually requiring the canonicalization to > pass. While I actually think this warning is counter-productive, if we were to do so, value-regex given for a bool-or-int type should also be warned if it does not name a boolean value and is not an integer. With the way you laid out the "use enum to tell what kind of token value_regex argument has" pattern, I think support for "--type=int" to normalize human-readable numbers would also fall out naturally, which is nice.
