[RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE

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

On Wed, Jan 28, 2026 at 07:42:34PM +0530, Pushkar Singh wrote:

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

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 <peff@peff.net> wrote: