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

From: Jeff King <peff@peff.net>
Date: Mar 6, 2012, 08:06 UTC
Message-ID: <20120306080624.GB21199@sigill.intra.peff.net>
In-Reply-To: <7veht626ex.fsf@alter.siamese.dyndns.org>

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

Show 13 quoted lines

> 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