Re: [PATCH 1/4] Split up default "core" config parsing into helper routine

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 18, 2008, 22:58 UTC
Message-ID: <alpine.LFD.1.10.0806181552590.2907@woody.linux-foundation.org>
In-Reply-To: <20080618224919.GA22599@sigill.intra.peff.net>

On Wed, 18 Jun 2008, Jeff King wrote:

Show 6 quoted lines

> 
> Maybe it would be easier still to read (and unmeasurably more efficient)
> to actually do it like:
> 
>         if (!prefixcmp(var, "core."))
>                 return git_default_core_config(var+5, value);

I considered it, but I think that screws up error reporting (ie if some value is unparseable, it would then print out the wrong variable name).

It would also have made the patches much less obvious. So it's a "future enhancement" thing.

> I was curious a while ago and instrumented git_config to write the PID
> to a tempfile each time it was called. Most git programs parse the
> config files (.git/config, ~/.gitconfig, /etc/gitconfig) three times
> each, with some doing it as many as five times.

Yeah, I know. I love the config file format (quite frankly, anybody who thinks XML and friends are sane is a total moron and should be shot before they reproduce), but the whole parsing code was a really quick hack.

I've several times wanted to rewrite it so that it does something smarter (parse it once, save it in a nice data structure), but let's face it, the upside is rather small. So I've never really ended up having the energy.

> Then we could do useful things like say "you specified core.foobar, but
> there is no such variable."

No. We could already do that (just add it to the end of git_default_core_config - it should be called last even if there was a chain), but avoid doing that very much on purpose.

Why? Because it's really irritating to have a parser that complains about newer values (or old deprecated ones) that don't matter for that version of the program.

			Linus