Re: [RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE
- From
Jeff King <peff@peff.net>
- Date
- Jan 29, 2026, 11:24 UTC
- Message-ID
- <20260129112446.GB1285720@coredump.intra.peff.net>
- In-Reply-To
- <CALE2CrQD11Qa+wGVhsF8JwkuwkLWkDf9kGvs1NM2dsYFuPgUKA@mail.gmail.com>
On Wed, Jan 28, 2026 at 07:42:34PM +0530, Pushkar Singh wrote:
Show 9 quoted lines
> The documentation says matching is performed against a canonicalized > lowercase key, but the current implementation achieves this by modifying > the regex itself. > > Would it make sense to stop rewriting the pattern and instead use REG_ICASE > when compiling the regex? This would preserve user-provided regexes, support > more complex expressions, simplify the code, and eliminate the NEEDSWORK. > > If this direction sounds reasonable, I’d be happy to follow up with a patch.
No, I don't think that would yield correct results, because the whole config key is not case-insensitive. The "subsection" (the middle part of a key with two dots, like "section.SubSection.key") is case sensitive. That's why we only lowercase the regex up to the first dot (and after the last dot).
So as a concrete example:
git config foo.Bar.baz value git config --get-regexp foo.bar.baz
should not match (and does not currently). Whereas:
git config --get-regexp foo.Bar.baz
would (and does).
If anything, I think we should consider deprecating the auto-lowercasing of the regex.
The "right" thing for callers to do is to downcase their regexes themselves, in order to match the canonicalized name (which we do document; I think it was added around the same time as the comment you found). So any lowercasing we do is a favor to callers to make their lives easier. The fact that we can't do it as thoroughly as possible is perhaps OK, but I also think we could actually screw up their regex in some extreme cases (say, by thinking we found a dot as a section separator that isn't really one). Which is gross, but nobody seems to have cared too much.
OTOH, it does help the regex queries match the regular ones. We will canonicalize "git config Foo.Bar.Baz" into "foo.Bar.baz", which we can do unambiguously. And especially since we document names as camelCase, people tend to write things like "fetch.unpackLimit" in their queries. I don't think we'd ever want to stop making that work (though interestingly, I do not think we document that anywhere).
So probably I'd do nothing. ;)
-Peff