# git-config: case insensitivity for subsections 9 messages from 2011-08-18 to 2011-08-29. Participants: milki, Jeff King, Junio C Hamano, Alex Vandiver. Thread: https://gitlist.dev/t/28149 ## milki, 2011-08-18 06:35 Subject: git-config: case insensitivity for subsections Message-ID: <20110818063528.GH13342@hal.rescomp.berkeley.edu> URL: https://gitlist.dev/e/20110818063528.GH13342%40hal.rescomp.berkeley.edu ``` 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. -- milki ``` ## Jeff King, 2011-08-25 20:58 Subject: Re: git-config: case insensitivity for subsections Message-ID: <20110825205849.GA10384@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110825205849.GA10384%40sigill.intra.peff.net In-Reply-To: <20110818063528.GH13342@hal.rescomp.berkeley.edu> ``` 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 ``` ## Junio C Hamano, 2011-08-25 21:32 Subject: Re: git-config: case insensitivity for subsections Message-ID: <7vpqjti3dq.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vpqjti3dq.fsf%40alter.siamese.dyndns.org In-Reply-To: <20110825205849.GA10384@sigill.intra.peff.net> ``` Jeff King writes: > 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? 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. ``` ## Jeff King, 2011-08-25 21:39 Subject: Re: git-config: case insensitivity for subsections Message-ID: <20110825213952.GA16914@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110825213952.GA16914%40sigill.intra.peff.net In-Reply-To: <7vpqjti3dq.fsf@alter.siamese.dyndns.org> ``` On Thu, Aug 25, 2011 at 02:32:17PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > 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? > > 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. 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 > 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. It's in Documentation/config.txt. It seems to blame to e136f33 (Documentation/config.txt: Document config file syntax better, 2007-01-22). -Peff ``` ## milki, 2011-08-25 21:57 Subject: Re: git-config: case insensitivity for subsections Message-ID: <20110825215757.GA94231@hal.rescomp.berkeley.edu> URL: https://gitlist.dev/e/20110825215757.GA94231%40hal.rescomp.berkeley.edu In-Reply-To: <20110825205849.GA10384@sigill.intra.peff.net> ``` On 16:58 Thu 25 Aug , Jeff King wrote: > 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. 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. ``` ## Alex Vandiver, 2011-08-29 00:50 Subject: Re: git-config: case insensitivity for subsections Message-ID: <1314579031.10094.19.camel@umgah.localdomain> URL: https://gitlist.dev/e/1314579031.10094.19.camel%40umgah.localdomain In-Reply-To: <20110825215757.GA94231@hal.rescomp.berkeley.edu> ``` On Thu, 2011-08-25 at 14:57 -0700, milki wrote: > This was simply surprising as I was trying to figure out what exactly > case sensitivity meant and how it affected 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. 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 ``` ## milki, 2011-08-29 05:42 Subject: Re: git-config: case insensitivity for subsections Message-ID: <20110829054240.GB94231@hal.rescomp.berkeley.edu> URL: https://gitlist.dev/e/20110829054240.GB94231%40hal.rescomp.berkeley.edu In-Reply-To: <1314579031.10094.19.camel@umgah.localdomain> ``` On 20:50 Sun 28 Aug , Alex Vandiver 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. 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 ``` ## Jeff King, 2011-08-29 15:58 Subject: Re: git-config: case insensitivity for subsections Message-ID: <20110829155819.GA756@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110829155819.GA756%40sigill.intra.peff.net In-Reply-To: <20110829054240.GB94231@hal.rescomp.berkeley.edu> ``` On Sun, Aug 28, 2011 at 10:42:40PM -0700, milki wrote: > A user gave me a link [1] to his git-config and I cannot correctly > parse, for example, his alias.last. > [...] > [1] https://github.com/kergoth/homefiles/blob/master/.gitconfig#L67 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 ``` ## Alex Vandiver, 2011-08-29 16:47 Subject: Re: git-config: case insensitivity for subsections Message-ID: <1314636466.17526.16.camel@umgah.localdomain> URL: https://gitlist.dev/e/1314636466.17526.16.camel%40umgah.localdomain In-Reply-To: <20110829155819.GA756@sigill.intra.peff.net> ``` On Mon, 2011-08-29 at 11:58 -0400, Jeff King 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). Yes, those should be escaped to do what he probably intends. Nonetheless, certainly a parsing bug. > 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 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 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(-) diff --git a/lib/Config/GitLike.pm b/lib/Config/GitLike.pm index c19911e..8a7195b 100644 --- a/lib/Config/GitLike.pm +++ b/lib/Config/GitLike.pm @@ -333,7 +333,7 @@ sub parse_content { $value .= $v; } # valid value (no escape codes) - elsif ($c =~ s/\A([^\t \\\n]+)//im) { + elsif ($c =~ s/\A([^\t \\\n"]+)//im) { $value .= $1; # unparseable } -- 1.7.4.1 ```