patch, 2 partsComplain in the tests about git config not failing with, keys without a section

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

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

What are these lines?

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".

On 02-03-2012 19:40, Junio C Hamano wrote:

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

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

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:

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

Jeff King <peff@peff.net> writes:

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?

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

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