From: Pushkar Singh Date: Thu, 29 Jan 2026 12:22:39 GMT Subject: Re: [RFC] config --get-regexp: avoid rewriting regex patterns; consider REG_ICASE Message-ID: 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