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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html