On Wed, 18 Jun 2008, Jeff King wrote:
quoted text
> 
> 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.

quoted text
> 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.

quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html