Re: [GSOC] Git Configuration API improvements

> On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote:
>
>> On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> > karthik nayak <karthik.188@gmail.com> writes:
>> >
>> >> Currently we have multiple invocation of git_config() in an
>> >> individual invocation of git() which is not efficient. Also, it is
>> >> hard to implement new features,
>> >
>> > I think efficiency is not a real concern here. Config files are small
>> > and easy to parse, so parsing them multiple times isn't really
>> > noticeable from the performance point of view.
>> >
>> > OTOH, the extensibility is a real concern, and that should be the main
>> > motivation for the project.
>>
>> Thanks. I understand what you mean. extensibility is the main motivation of the
>> project, i think that by implementing the cache system we can fix the
>> small problems
>> (reappearing of headers while setting and unsetting configs) and also
>> implement new features
>> like to unset a config easily.
>
> I think the most interesting part of the config idea is turning the
> fetching of config variables "inside out".
>
> That is, right now we turn control over to the config code, which
> invokes our callbacks. So we see all variables in sequence, and pick out
> the ones that are interesting.  We implement precedence with a "last one
> wins" technique where we keep overwriting a variable with subsequent
> config options.
>
> This can lead to difficult ordering situations, such as when a config
> option _might_ be respected based on another factor (e.g., the presence
> of a command line option, as in the status.branch option).
>
> It also means that it's impossible to tell after the fact whether a
> value was set explicitly on the command line, by config, or if we are
> using a system default. Most of the time this doesn't matter, but there
> are a few cases where we care, and we end up having to manually manage
> a separate flag in each case.
>
> By the phrase "inside out" above, I mean that we could read all config,
> and then fetch individual values as we need them. We do need to care
> about efficiency here, but only insofar as we don't cause any
> regressions (that is, the current system is fine speed-wise, we just
> need to make sure that we do not create new problems by calling a slow
> lookup in a tight loop or anything like that).
>
> -Peff