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

>
> 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