[PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[Rune Schjellerup Philosof]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

From c4fc13a5a1e8c1eab9873232e6e8b7e0523cd6ea Mon Sep 17 00:00:00 2001
From: Rune Philosof <rune.git@philosof.dk>
Date: Fri, 2 Mar 2012 10:42:23 +0100
Subject: [PATCH 1/2] Complain in the tests about git config not failing with
 keys without a section

git is supposed to fail when having a key without a section, but does not.

Signed-off-by: Rune Philosof <rune.git@philosof.dk>
---
 t/t1300-repo-config.sh |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 5f249f6..81ccad5 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -928,6 +928,11 @@ test_expect_success 'git -c "key=value" support' '
 	test_must_fail git -c name=value config core.name
 '

+test_expect_failure 'No section' '
+	echo "fail=true" > failconf &&
+	test_must_fail git config --file failconf --list
+'
+
 test_expect_success 'key sanity-checking' '
 	test_must_fail git config foo=bar &&
 	test_must_fail git config foo=.bar &&
-- 
1.7.5.4


[-- Attachment #2: S/MIME-signeret meddelelse --]
[-- Type: application/pkcs7-signature, Size: 2033 bytes --]

Re: [PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[Junio C Hamano]

Rune Schjellerup Philosof <rune@philosof.dk> writes:

> From c4fc13a5a1e8c1eab9873232e6e8b7e0523cd6ea Mon Sep 17 00:00:00 2001
> From: Rune Philosof <rune.git@philosof.dk>
> Date: Fri, 2 Mar 2012 10:42:23 +0100
> Subject: [PATCH 1/2] Complain in the tests about git config not failing with
>  keys without a section

What are these lines?

>
> git is supposed to fail when having a key without a section, but does not.

I do not think anybody said it is supposed to fail in this case.

Historically, we always allowed single level names in our configuration
parser, at least for reading, from pretty much day one, I think.  The
documentation only talks about two and three level names, because we do
not use such a name ourselves in the code, and the behaviour for a single
level name is just "undefined", which is very different from "must fail".

Re: [PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[Rune Philosof]

On 02-03-2012 19:40, Junio C Hamano wrote:
>> git is supposed to fail when having a key without a section, but does not.
> I do not think anybody said it is supposed to fail in this case.
>
> the behaviour for a single level name is just "undefined", which is very different from "must fail".

Quoting from `git help config`:
This command will fail if:
  3. no section was provided,
...
under SYNTAX
  Each variable must belong to some section, which means that there must 
be a section header before the first
        setting of a variable.

--
Greeting
Rune Philosof

Re: [PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[Jeff King]

On Mon, Mar 05, 2012 at 08:59:29AM +0100, Rune Philosof wrote:

> On 02-03-2012 19:40, Junio C Hamano wrote:
> >>git is supposed to fail when having a key without a section, but does not.
> >I do not think anybody said it is supposed to fail in this case.
> >
> >the behaviour for a single level name is just "undefined", which is very different from "must fail".
> 
> Quoting from `git help config`:
> This command will fail if:
>  3. no section was provided,

The text you are quoting is not about what is in the config file, but
rather the config name given on the command line (which we would be
trying to look up). And we do correctly complain about that:

  $ git config foo
  error: key does not contain a section: foo

But:

> under SYNTAX
>  Each variable must belong to some section, which means that there
> must be a section header before the first
>        setting of a variable.

Yes, everything is supposed to be in a section.  Historically we have
not complained, but instead just treated it as a single-level variable.
For internal git use this never mattered, as git only looked at
variables with section names. For "git config foo", it also does not
matter, since we will notice the lack of section before even doing a
lookup.

For "git config --list", as you noticed, we include it in the output. I
suspect we should simply omit it as cruft. But we could also issue a
warning, and/or die.

-Peff

Re: [PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> For "git config --list", as you noticed, we include it in the output. I
> suspect we should simply omit it as cruft. But we could also issue a
> warning, and/or die.

A new warning might be worth if we were to suddenly start omitting
them from --list output, but dying won't fly well.

People have been happily lived with their config with such lines
that do not affect what git does, but a new version of git starts to
"die" on them.  For what purpose?  Whom is such a change designed to
help?

Re: [PATCH 1/2] Complain in the tests about git config not failing with, keys without a section

[Jeff King]

On Mon, Mar 05, 2012 at 11:29:10AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > For "git config --list", as you noticed, we include it in the output. I
> > suspect we should simply omit it as cruft. But we could also issue a
> > warning, and/or die.
> 
> A new warning might be worth if we were to suddenly start omitting
> them from --list output, but dying won't fly well.
> 
> People have been happily lived with their config with such lines
> that do not affect what git does, but a new version of git starts to
> "die" on them.  For what purpose?  Whom is such a change designed to
> help?

The only people you might help are those who would like to be informed
that their config file is bogus, and that those entries are being
ignored (which might be an error, for example, if they accidentally
deleted a section header). But I don't think it's a huge deal; it
certainly is not the first config error one could make that isn't
detected (e.g., you could just as easily typo "core.quotpath", and git
will never say a word).

A warning probably serves to inform such people just as well as dying.
I am actually just fine with omitting it from --list, too. We can be
liberal in what we accept from people's config files, and just pretend
that bogus things do not exist (just like core.quotpath ends up being
silently ignored). You cannot access a section-less variable via "git
config" directly, so it is probably better to just act as if it does not
exist.

For the record, I am also fine with just leaving it as-is. This seems
like such a low priority that until somebody shows up with a patch, I
can't bring myself to care too much.

-Peff