{"thread":{"id":"28149","subject":"git-config: case insensitivity for subsections","startedAt":"2011-08-18T06:35:28Z","lastAt":"2011-08-29T16:47:46Z","messageCount":9,"participants":["milki","Jeff King","Junio C Hamano","Alex Vandiver"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"173728","messageId":"20110818063528.GH13342@hal.rescomp.berkeley.edu","threadId":"28149","inReplyTo":null,"subject":"git-config: case insensitivity for subsections","fromName":"milki","fromEmail":"milki@rescomp.berkeley.edu","sentAt":"2011-08-18T06:35:28Z","receivedAt":"2011-08-18T06:35:28Z","isPatch":false,"sender":{"key":"milki@rescomp.berkeley.edu","avatar":"https://gravatar.com/avatar/dbe8b44fae13d8846b110e1bd18a9f61f55089b728372f02a424bee1f825308f?d=mp&s=160"},"body":"In git-config(1):\n\nThere is also a case insensitive alternative [section.subsection]\nsyntax. In this syntax, subsection names follow the same restrictions\nas for section names.\n\nIf I define [section.SUBSECTION] (aka, not all lowercase), I cannot\nuse: git config section.SUBSECTION.option, but rather only git config\nsection.subsection.option. Furthermore, If I also define a [section\n\"SUBSECTION\"], the two sections are not merged.\n\nI believe this differs from the case insensitity that is used for\nsections: [section] and [SECTION] would be considered the same section.\n\nIs this the proper behaviour for the case insensititve alternative for\nsubsections?\n\nThanks.\n\n-- \nmilki\n"},{"id":"174264","messageId":"20110825205849.GA10384@sigill.intra.peff.net","threadId":"28149","inReplyTo":"20110818063528.GH13342@hal.rescomp.berkeley.edu","subject":"Re: git-config: case insensitivity for subsections","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-25T20:58:49Z","receivedAt":"2011-08-25T20:58:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 17, 2011 at 11:35:28PM -0700, milki wrote:\n\n> If I define [section.SUBSECTION] (aka, not all lowercase), I cannot\n> use: git config section.SUBSECTION.option, but rather only git config\n> section.subsection.option.\n\nThe way the config code works (both internally and via git-config), is\nto read through the config files, convert each key into a canonical\nformat (downcasing the section and key, and either preserving the\ncase for the subsection in '[section \"FOO\"]' or downcasing it for\n'[section.FOO]'), and then compare the result to the canonical version\nof what you're looking for.\n\nIn other words, if you want to match section.SUBSECTION, you should\nalways ask for the canonical version \"section.subsection.whatever\".\n\nWe could try to be nicer and handle this automatically, but it's\nnontrivial. When you say \"git config foo.BAR.baz\", we don't know if you\nmean for \"BAR\" to be case-insensitive or not. So it would involve\ncarrying more information around about how the section header in the\nconfig file was actually parsed. Not impossible, but it would involve\nchanging the internal git_config interface and tweaking a lot of code to\nmatch.\n\nIs there a reason that you can't use the canonical version in your \"git\nconfig\" invocation? Or was it simply confusing that it didn't work? I'd\nmuch prefer to document this limitation in git-config(1) than change the\ncode.\n\n> Furthermore, If I also define a [section \"SUBSECTION\"], the two\n> sections are not merged.\n\nI'm not sure it makes sense to do so. I can see how:\n\n  [section.SUBSECTION]\n\nand\n\n  [section.subsection]\n\nshould be merged. But isn't:\n\n  [section \"SUBSECTION\"]\n\nconceptually a different section entirely?\n\nAgain, do you have a real-world use for this?\n\n-Peff\n"},{"id":"174271","messageId":"7vpqjti3dq.fsf@alter.siamese.dyndns.org","threadId":"28149","inReplyTo":"20110825205849.GA10384@sigill.intra.peff.net","subject":"Re: git-config: case insensitivity for subsections","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-25T21:32:17Z","receivedAt":"2011-08-25T21:32:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I'm not sure it makes sense to do so. I can see how:\n>\n>   [section.SUBSECTION]\n>\n> and\n>\n>   [section.subsection]\n>\n> should be merged. But isn't:\n>\n>   [section \"SUBSECTION\"]\n>\n> conceptually a different section entirely?\n\nI still recall getting scolded by Linus after writing [sec.tion]; this was\nway back when he was still active on this list. I essentially was told\nthat [sec \"tion\"] is _the_ only supported way, and [sec.tion] may work but\nit purely does by accident, not by design.\n\nDo we still even list the bogus [section.SUBSECTION] syntax anywhere in\nour docs? If so, we should remove them and if not we simply just should\ndeprecate the code to read such input.\n"},{"id":"174272","messageId":"20110825213952.GA16914@sigill.intra.peff.net","threadId":"28149","inReplyTo":"7vpqjti3dq.fsf@alter.siamese.dyndns.org","subject":"Re: git-config: case insensitivity for subsections","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-25T21:39:52Z","receivedAt":"2011-08-25T21:39:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 25, 2011 at 02:32:17PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I'm not sure it makes sense to do so. I can see how:\n> >\n> >   [section.SUBSECTION]\n> >\n> > and\n> >\n> >   [section.subsection]\n> >\n> > should be merged. But isn't:\n> >\n> >   [section \"SUBSECTION\"]\n> >\n> > conceptually a different section entirely?\n> \n> I still recall getting scolded by Linus after writing [sec.tion]; this was\n> way back when he was still active on this list. I essentially was told\n> that [sec \"tion\"] is _the_ only supported way, and [sec.tion] may work but\n> it purely does by accident, not by design.\n\nHmm. It is a little weird that color.branch.local would have to be\nspelled:\n\n  [color \"branch\"]\n    local = blue\n\nand that the \"branch\" must be case-sensitive.\n\nBut then, that wouldn't be my first complaint about our config syntax,\nwhich sort of pretends to be hierarchical (with the dot-syntax) but\nisn't really. E.g., I'd really much rather it be spelled:\n\n  [color]\n    branch.local = blue\n\n> Do we still even list the bogus [section.SUBSECTION] syntax anywhere in\n> our docs? If so, we should remove them and if not we simply just should\n> deprecate the code to read such input.\n\nIt's in Documentation/config.txt. It seems to blame to e136f33\n(Documentation/config.txt: Document config file syntax better,\n2007-01-22).\n\n-Peff\n"},{"id":"174275","messageId":"20110825215757.GA94231@hal.rescomp.berkeley.edu","threadId":"28149","inReplyTo":"20110825205849.GA10384@sigill.intra.peff.net","subject":"Re: git-config: case insensitivity for subsections","fromName":"milki","fromEmail":"milki@rescomp.berkeley.edu","sentAt":"2011-08-25T21:57:57Z","receivedAt":"2011-08-25T21:57:57Z","isPatch":false,"sender":{"key":"milki@rescomp.berkeley.edu","avatar":"https://gravatar.com/avatar/dbe8b44fae13d8846b110e1bd18a9f61f55089b728372f02a424bee1f825308f?d=mp&s=160"},"body":"On 16:58 Thu 25 Aug     , Jeff King wrote:\n> Is there a reason that you can't use the canonical version in your \"git\n> config\" invocation? Or was it simply confusing that it didn't work? I'd\n> much prefer to document this limitation in git-config(1) than change the\n> code.\n\nThis was simply surprising as I was trying to figure out what exactly\ncase sensitivity meant and how it affacted sections. This definitely\nclears this up for me. I'm actually working on a config parser because I\ndon't think I've seen a complete implementation besides git-config in a\ndifferent language.\n"},{"id":"174436","messageId":"1314579031.10094.19.camel@umgah.localdomain","threadId":"28149","inReplyTo":"20110825215757.GA94231@hal.rescomp.berkeley.edu","subject":"Re: git-config: case insensitivity for subsections","fromName":"Alex Vandiver","fromEmail":"alex@chmrr.net","sentAt":"2011-08-29T00:50:31Z","receivedAt":"2011-08-29T00:50:31Z","isPatch":false,"sender":{"key":"alex@chmrr.net","avatar":"https://avatars.githubusercontent.com/u/28347?v=4"},"body":"On Thu, 2011-08-25 at 14:57 -0700, milki wrote:\n> This was simply surprising as I was trying to figure out what exactly\n> case sensitivity meant and how it affected sections. This definitely\n> clears this up for me. I'm actually working on a config parser because I\n> don't think I've seen a complete implementation besides git-config in a\n> different language.\n\nFor reference, https://github.com/bestpractical/config-gitlike/ is a\ncomplete parser for git config files written in perl, which passes git's\nconfig test suite (among other tests).  Which is not terribly\nsurprising, since its parsing algorithm is strongly derived from\nconfig.c's.\n - Alex\n"},{"id":"174441","messageId":"20110829054240.GB94231@hal.rescomp.berkeley.edu","threadId":"28149","inReplyTo":"1314579031.10094.19.camel@umgah.localdomain","subject":"Re: git-config: case insensitivity for subsections","fromName":"milki","fromEmail":"milki@rescomp.berkeley.edu","sentAt":"2011-08-29T05:42:40Z","receivedAt":"2011-08-29T05:42:40Z","isPatch":false,"sender":{"key":"milki@rescomp.berkeley.edu","avatar":"https://gravatar.com/avatar/dbe8b44fae13d8846b110e1bd18a9f61f55089b728372f02a424bee1f825308f?d=mp&s=160"},"body":"On 20:50 Sun 28 Aug     , Alex Vandiver wrote:\n> For reference, https://github.com/bestpractical/config-gitlike/ is a\n> complete parser for git config files written in perl, which passes git's\n> config test suite (among other tests).  Which is not terribly\n> surprising, since its parsing algorithm is strongly derived from\n> config.c's.\n\nYes, I've been looking at it and forked a majority of it into python,\nbut I can't seem to replicate some of the expected quoting behaviour of\ngit-config, among other things (now off-topic). My implementation so\nfar can be seen at [0]. A user gave me a link [1] to his git-config\nand I cannot correctly parse, for example, his alias.last.\n\n-milki\n\n\n[0] https://github.com/jelmer/dulwich/pull/31#issuecomment-1918904\n[1] https://github.com/kergoth/homefiles/blob/master/.gitconfig#L67\n"},{"id":"174459","messageId":"20110829155819.GA756@sigill.intra.peff.net","threadId":"28149","inReplyTo":"20110829054240.GB94231@hal.rescomp.berkeley.edu","subject":"Re: git-config: case insensitivity for subsections","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-29T15:58:19Z","receivedAt":"2011-08-29T15:58:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 28, 2011 at 10:42:40PM -0700, milki wrote:\n\n> A user gave me a link [1] to his git-config and I cannot correctly\n> parse, for example, his alias.last.\n> [...]\n> [1] https://github.com/kergoth/homefiles/blob/master/.gitconfig#L67\n\nIsn't his config somewhat broken?  It looks like this:\n\n  last = \"!f(){ since=\"$1\"; shift; git lg --since=\\\"last $since\\\" \"$@\"; }; f\"\n\nThose interior double-quotes should all be backslash-escaped. I didn't\ncheck, but git should interpret this as:\n\n  !f(){ since=$1; shift; git lg --since=\"last $since\" $@; }; f\n\nwhich is probably not quite what he wanted (the quotes around $1 were\nactually superfluous, but the ones around $@ are important).\n\nThat being said, I think it is intentional that the value is not just \"a\nsingle double-quoted chunk\" but rather could consist of several quoted\n(or unquoted) chunks concatenated together. What does your parser think\nof:\n\n  [foo]\n    bar = \"foo\"bar\"baz\"\n\nIt should be:\n\n  $ git config foo.bar\n  foobarbaz\n\n-Peff\n"},{"id":"174466","messageId":"1314636466.17526.16.camel@umgah.localdomain","threadId":"28149","inReplyTo":"20110829155819.GA756@sigill.intra.peff.net","subject":"Re: git-config: case insensitivity for subsections","fromName":"Alex Vandiver","fromEmail":"alex@chmrr.net","sentAt":"2011-08-29T16:47:46Z","receivedAt":"2011-08-29T16:47:46Z","isPatch":false,"sender":{"key":"alex@chmrr.net","avatar":"https://avatars.githubusercontent.com/u/28347?v=4"},"body":"On Mon, 2011-08-29 at 11:58 -0400, Jeff King wrote:\n> Isn't his config somewhat broken?  It looks like this:\n> \n>   last = \"!f(){ since=\"$1\"; shift; git lg --since=\\\"last $since\\\" \"$@\"; }; f\"\n> \n> Those interior double-quotes should all be backslash-escaped. I didn't\n> check, but git should interpret this as:\n> \n>   !f(){ since=$1; shift; git lg --since=\"last $since\" $@; }; f\n> \n> which is probably not quite what he wanted (the quotes around $1 were\n> actually superfluous, but the ones around $@ are important).\n\nYes, those should be escaped to do what he probably intends.\nNonetheless, certainly a parsing bug.\n\n> That being said, I think it is intentional that the value is not just \"a\n> single double-quoted chunk\" but rather could consist of several quoted\n> (or unquoted) chunks concatenated together. What does your parser think\n> of:\n> \n>   [foo]\n>     bar = \"foo\"bar\"baz\"\n> \n> It should be:\n> \n>   $ git config foo.bar\n>   foobarbaz\n\nAnd with the below patch to config-gitlike, it does -- thanks for the\nbug report.\n - Alex\n\n--------8<-----------\nFrom 433dcc2f739c8906c65329a899b45424c146535c Mon Sep 17 00:00:00 2001\nFrom: Alex Vandiver <alexmv@bestpractical.com>\nDate: Mon, 29 Aug 2011 12:04:37 -0400\nSubject: [PATCH] Allow quoted strings to adjoin directly to unquoted strings\n\nThis resolves a bug wherein:\n\n    [foo]\n        bar = \"foo\"bar\"baz\"\n\n...was incorrectly parsed as << foo.bar=foobar\"baz\" >> and not the\ncorrect << foo.bar=foobarbaz >>.  Make the fall-through value not\nconsume quotes when consuming a token, as it should be instead parsed as\nthe start of a quoted-value.  This bug was only evident when the quoted\nvalue abutted the unquoted value with no separating space.\n---\n lib/Config/GitLike.pm |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/lib/Config/GitLike.pm b/lib/Config/GitLike.pm\nindex c19911e..8a7195b 100644\n--- a/lib/Config/GitLike.pm\n+++ b/lib/Config/GitLike.pm\n@@ -333,7 +333,7 @@ sub parse_content {\n                     $value .= $v;\n                 }\n                 # valid value (no escape codes)\n-                elsif ($c =~ s/\\A([^\\t \\\\\\n]+)//im) {\n+                elsif ($c =~ s/\\A([^\\t \\\\\\n\"]+)//im) {\n                     $value .= $1;\n                 # unparseable\n                 }\n-- \n1.7.4.1\n"}]}