git-config: case insensitivity for subsections

In git-config(1):

There is also a case insensitive alternative [section.subsection] syntax. In this syntax, subsection names follow the same restrictions as for section names.

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. Furthermore, If I also define a [section "SUBSECTION"], the two sections are not merged.

I believe this differs from the case insensitity that is used for sections: [section] and [SECTION] would be considered the same section.

Is this the proper behaviour for the case insensititve alternative for subsections?

Thanks.

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

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.

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

Jeff King <peff@peff.net> writes:

I still recall getting scolded by Linus after writing [sec.tion]; this was way back when he was still active on this list. I essentially was told that [sec "tion"] is _the_ only supported way, and [sec.tion] may work but it purely does by accident, not by design.

Do we still even list the bogus [section.SUBSECTION] syntax anywhere in our docs? If so, we should remove them and if not we simply just should deprecate the code to read such input.

On Thu, Aug 25, 2011 at 02:32:17PM -0700, Junio C Hamano wrote:

Hmm. It is a little weird that color.branch.local would have to be spelled:

  [color "branch"]
    local = blue

and that the "branch" must be case-sensitive.

But then, that wouldn't be my first complaint about our config syntax, which sort of pretends to be hierarchical (with the dot-syntax) but isn't really. E.g., I'd really much rather it be spelled:

  [color]
    branch.local = blue

It's in Documentation/config.txt. It seems to blame to e136f33 (Documentation/config.txt: Document config file syntax better, 2007-01-22).

-Peff

On 16:58 Thu 25 Aug     , Jeff King wrote:

This was simply surprising as I was trying to figure out what exactly case sensitivity meant and how it affacted sections. This definitely clears this up for me. I'm actually working on a config parser because I don't think I've seen a complete implementation besides git-config in a different language.

On Thu, 2011-08-25 at 14:57 -0700, milki wrote:

For reference, https://github.com/bestpractical/config-gitlike/ is a
complete parser for git config files written in perl, which passes git's
config test suite (among other tests).  Which is not terribly
surprising, since its parsing algorithm is strongly derived from
config.c's.
 - Alex

On 20:50 Sun 28 Aug     , Alex Vandiver wrote:

Yes, I've been looking at it and forked a majority of it into python, but I can't seem to replicate some of the expected quoting behaviour of git-config, among other things (now off-topic). My implementation so far can be seen at [0]. A user gave me a link [1] to his git-config and I cannot correctly parse, for example, his alias.last.

-milki

[0] https://github.com/jelmer/dulwich/pull/31#issuecomment-1918904 [1] https://github.com/kergoth/homefiles/blob/master/.gitconfig#L67

On Sun, Aug 28, 2011 at 10:42:40PM -0700, milki wrote:

Isn't his config somewhat broken?  It looks like this:

  last = "!f(){ since="$1"; shift; git lg --since=\"last $since\" "$@"; }; f"

Those interior double-quotes should all be backslash-escaped. I didn't check, but git should interpret this as:

  !f(){ since=$1; shift; git lg --since="last $since" $@; }; f

which is probably not quite what he wanted (the quotes around $1 were actually superfluous, but the ones around $@ are important).

That being said, I think it is intentional that the value is not just "a single double-quoted chunk" but rather could consist of several quoted (or unquoted) chunks concatenated together. What does your parser think of:

  [foo]
    bar = "foo"bar"baz"

It should be:

  $ git config foo.bar
  foobarbaz

-Peff

On Mon, 2011-08-29 at 11:58 -0400, Jeff King wrote:

Yes, those should be escaped to do what he probably intends. Nonetheless, certainly a parsing bug.

And with the below patch to config-gitlike, it does -- thanks for the
bug report.
 - Alex

--------8<-----------
From 433dcc2f739c8906c65329a899b45424c146535c Mon Sep 17 00:00:00 2001
From: Alex Vandiver <alexmv@bestpractical.com>
Date: Mon, 29 Aug 2011 12:04:37 -0400
Subject: [PATCH] Allow quoted strings to adjoin directly to unquoted strings

This resolves a bug wherein:

    [foo]
        bar = "foo"bar"baz"

...was incorrectly parsed as << foo.bar=foobar"baz" >> and not the
correct << foo.bar=foobarbaz >>.  Make the fall-through value not
consume quotes when consuming a token, as it should be instead parsed as
the start of a quoted-value.  This bug was only evident when the quoted
value abutted the unquoted value with no separating space.
---
 lib/Config/GitLike.pm |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)