Martin Ågren [off-list ref] writes:
git config --type=bool --name-only --get-regexp '^foo\.' true
...
This patch series teaches `git config` to canonicalize the incoming
"value_regex" ("true" in the example above), then canonicalize candidate
values as we go through the config. Or if you will, `git config` learns
a brand new type of regex, corresponding to the different ways there are
of spelling "true" and "false", respectively.
Nice ;-)
`--type=bool-or-int` gets the same treatment, except we need to to be
able to handle the ints and regexes matching particular ints that we
must expect.
Hmm, so I can say 1024k or 1m and that would match 1048576?
Doubly nice.
Looking forward to reading it thru.
Hi Junio
On Thu, 14 Nov 2019 at 03:19, Junio C Hamano [off-list ref] wrote:
Martin Ågren [off-list ref] writes:
quoted
`--type=bool-or-int` gets the same treatment, except we need to to be
able to handle the ints and regexes matching particular ints that we
must expect.
Hmm, so I can say 1024k or 1m and that would match 1048576?
Doubly nice.
Looking forward to reading it thru.
Maybe you already noticed, but no, I didn't get to canonicalizing
integers like that. What I meant was, type=bool-or-int learns to handle
booleans similar to what I did to type=bool.
I don't feel entirely satisfied by some of my commit message oneliners.
They could make that a bit clearer, I think.
Not directly related to your question, but I realize now that with
type=bool-or-int, I only added the first of these example usages below
as a test. The second one is perhaps just as interesting.
$ ./git -c an.int=1 config --get --type=bool-or-int an.int 1
1
$ ./git -c an.int=1 config --get --type=bool-or-int an.int on
1
This last one emits "1". That's because by the time we've decided to
output the value, `format_config()` has some logic around
type=bool-or-int, but doesn't know about why exactly we selected this
an.int=1 in the first place
(git_parse_maybe_bool("1") == git_parse_maybe_bool_TEXT("on")).
Just after thinking about this for a short while, I can't immediately
say whether this second one should emit "1" or "true". My added
documentation is actually vague enough to allow both of these to
happen... I'll ponder this.
Martin