Re: git-config: case insensitivity for subsections

[Jeff King <peff@peff.net>]

On Wed, Aug 17, 2011 at 11:35:28PM -0700, milki wrote:

> If I define [section.SUBSECTION] (aka, not all lowercase), I cannot
> use: git config section.SUBSECTION.option, but rather only git config
> section.subsection.option.

The way the config code works (both internally and via git-config), is
to read through the config files, convert each key into a canonical
format (downcasing the section and key, and either preserving the
case for the subsection in '[section "FOO"]' or downcasing it for
'[section.FOO]'), and then compare the result to the canonical version
of what you're looking for.

In other words, if you want to match section.SUBSECTION, you should
always ask for the canonical version "section.subsection.whatever".

We could try to be nicer and handle this automatically, but it's
nontrivial. When you say "git config foo.BAR.baz", we don't know if you
mean for "BAR" to be case-insensitive or not. So it would involve
carrying more information around about how the section header in the
config file was actually parsed. Not impossible, but it would involve
changing the internal git_config interface and tweaking a lot of code to
match.

Is there a reason that you can't use the canonical version in your "git
config" invocation? Or was it simply confusing that it didn't work? I'd
much prefer to document this limitation in git-config(1) than change the
code.

> Furthermore, If I also define a [section "SUBSECTION"], the two
> sections are not merged.

I'm not sure it makes sense to do so. I can see how:

  [section.SUBSECTION]

and

  [section.subsection]

should be merged. But isn't:

  [section "SUBSECTION"]

conceptually a different section entirely?

Again, do you have a real-world use for this?

-Peff