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.
>
> We would probably want something like:
>
> static int do_warn_unknown_config;
>
> void warn_unknown_config(const char *key)
> {
> if (do_warn_unknown_config)
> warn("Unknown configuration variable %s", key);
> }
>
> and sprinkle that everywhere.
Your "sprinkle that everywhere" is a little harder than one might hope.
There is no code path that reads and claims to recognize _all_ of the
git config. In many cases, the git_*_config for individual subsystems
can reasonably lay claim to the whole of a "[heading]" section. But
there are exceptions even to that.
Diff config is split across git_diff_basic_config and
git_diff_ui_config. You would certainly not want to warn about
diff.color.* just because you are running a plumbing command which
happens not to recognize those entries.
And some headings have entries for several subsystems. remote.*.fetch is
used many places for calculating upstream branches. But only git-remote
looks at remote.*.skipDefaultUpdate.
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.
> An interesting issue is where to flip do_warn_unknown_config. A naïve
> and obvious implementation would do:
>
> static int git_default_core_config(const char *var, const char *value)
> {
> ...
> if (!strcmp(var, "core.warnunknownconfig")) {
> do_warn_unknown_config = git_config_bool(var, value);
> return 0;
> }
> ...
> }
>
> but that means the definition of this variable has to come very early in
> the configuration file to be effective.
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.
You could always just hoist into an environment variable which neatly
gets rid of the ordering problem.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html