Re: [PATCH] Generate a warning message if we find an unrecognized option.

[David Aguilar <davvid@gmail.com>]

On Mon, Feb 08, 2010 at 10:01:51PM -0500, Jeff King wrote:
> On Mon, Feb 08, 2010 at 04:59:12PM -0800, Junio C Hamano wrote:
> 
> > > And obviously that is weighed against the ability to notice things like
> > > typos. But if we are going to start complaining about unknown config, we
> > > would probably do better to complain about _all_ unknown config, and not
> > > just this one subsection.

No, please, please no.


> So in practice I think you will get quite spotty coverage. Which isn't
> to say it isn't necessarily worth doing, but I am personally not very
> excited about working on it. I do like the suggestion of making it
> optional, so that people who don't care about having a portable config
> can have the benefit of sanity-checking their config.
> 
> I would rather have a "git config --lint" command, but that is even
> harder, since we are not even loading most of the subsystems which know
> about the valid config options. And it presupposes that people will
> bother to actually run such a lint command.

This runs up against the same issue you pointed out
earlier--that older versions of git cannot adequately lint
configs from newer versions.

There are also config variables from unknown git scripts outside
of git.git that happen to use the git-config mechanism because
it is convenient.  It would be unfortunate to punish those who
chose to make up their own config variables by warning them
that git doesn't know about them.

I have to wonder if this is a non-existent problem.

Config variables are one-shot things.  You set them and forget
about them.  When you set it you are usually pretty well aware
of whether it's typoed because it simply does't work.
color.ui is a perfect example.  If it's typoed, you don't need
'git config --lint' to tell you, you already know by virtue of
using the thing.

Maintaining 'git config --lint' would also be a PITA since we'd
then have to remember to update yet another place in addition to
code and documentation.  And who's to say what gets to be "in"
and what doesn't?  git-gui, for example, has its own [gui]
namespace.  git-p4 has its own [git-p4] namespace, but it
lives in contrib/, etc. etc.

This seems like a bad idea to me.

-- 
		David