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 [off-list ref] wrote:

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

quoted

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