# [RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE 3 messages from 2026-01-28 to 2026-01-29. Participants: Pushkar Singh, Jeff King. Thread: https://gitlist.dev/t/64880 ## Pushkar Singh, 2026-01-28 14:12 Subject: [RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE Message-ID: URL: https://gitlist.dev/e/CALE2CrQD11Qa%2BwGVhsF8JwkuwkLWkDf9kGvs1NM2dsYFuPgUKA%40mail.gmail.com ``` Hi, While looking at builtin/config.c I noticed the following NEEDSWORK comment in get_value(): /* * NEEDSWORK: this naive pattern lowercasing obviously does not * work for more complex patterns like "^[^.]*Foo.*". */ Currently, git config --get-regexp emulates case-insensitive matching by lowercasing parts of the user-provided regex before compiling it. This breaks valid regular expressions and makes it impossible to express more complex patterns. For example: git config --add Foo.Bar baz git config --add foo.Baz qux git config --get-regexp '^[^.]*Foo.*' does not behave as expected because the pattern is rewritten before regcomp(). POSIX regex also does not support inline modifiers like (?i), so users currently have no way to explicitly request case-insensitive matching. 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. Thanks, Pushkar ``` ## Jeff King, 2026-01-29 11:24 Subject: Re: [RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE Message-ID: <20260129112446.GB1285720@coredump.intra.peff.net> URL: https://gitlist.dev/e/20260129112446.GB1285720%40coredump.intra.peff.net In-Reply-To: ``` On Wed, Jan 28, 2026 at 07:42:34PM +0530, Pushkar Singh wrote: > 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 ``` ## Pushkar Singh, 2026-01-29 12:22 Subject: Re: [RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE Message-ID: URL: https://gitlist.dev/e/CALE2CrQVnv7wcvD%2BewDD2js7%3DmUE4soLmsud1U2AoorBRwAoNw%40mail.gmail.com In-Reply-To: <20260129112446.GB1285720@coredump.intra.peff.net> ``` Thanks for the detailed explanation, that makes sense. I had missed the subsection case-sensitivity, so REG_ICASE would indeed be incorrect. Appreciate the context on the historical behavior and tradeoffs here. I'll drop this for now. Thanks, Pushkar On Thu, Jan 29, 2026 at 4:54 PM Jeff King wrote: > > On Wed, Jan 28, 2026 at 07:42:34PM +0530, Pushkar Singh wrote: > > > 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 ```