git-config: case insensitivity for subsections

git-config: case insensitivity for subsections

[milki]

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

Re: git-config: case insensitivity for subsections

[Jeff King]

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

Re: git-config: case insensitivity for subsections

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

Re: git-config: case insensitivity for subsections

[Jeff King]

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

> Jeff King <peff@peff.net> 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

Re: git-config: case insensitivity for subsections

[milki]

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.

Re: git-config: case insensitivity for subsections

[Alex Vandiver]

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

Re: git-config: case insensitivity for subsections

[milki]

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

Re: git-config: case insensitivity for subsections

[Jeff King]

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

Re: git-config: case insensitivity for subsections

[Alex Vandiver]

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 <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(-)

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