Re: RFC GSoC idea: git configuration caching (needs co-mentor!)

[Michael Haggerty <mhagger@alum.mit.edu>]

On 03/06/2014 08:24 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> I just wrote up the idea that fell out of the discussion [1] about the
>> other configuration features that I proposed.  As far as I am concerned,
>> it can be merged as soon as somebody volunteers as a co-mentor.  The
>> idea is embodied in a pull request against the git.github.io repository
>> [2]; the text is also appended below for your convenience.
>>
>> Michael
>>
>> [1] http://article.gmane.org/gmane.comp.version-control.git/242952
>> [2] https://github.com/git/git.github.io/pull/7
>>
>> ### git configuration API improvements
>>
>> There are many places in Git that need to read a configuration value.
>> Currently, each such site calls `git_config()`, which reads and parses
>> the configuration files every time that it is called.  This is
>> wasteful, because it results in the configuration files being
>> processed multiple times during a single `git` invocation.  It also
>> prevents the implementation of potential new features, like adding
>> syntax to allow a configuration file to unset a previously-set value.
>>
>> This goal of this project is to make configuration work as follows:
>>
>> * Read the configuration from files once and cache the results in an
>>   appropriate data structure in memory.
>>
>> * Change `git_config()` to iterate through the pre-read values in
>>   memory rather than re-reading the configuration files.
>>
>> * Add new API calls that allow the cache to be inquired easily and
>>   efficiently.  Rewrite other functions like `git_config_int()` to be
>>   cache-aware.
> 
> Are you sure about the second sentence of this item is what you
> want?
> 
> git_config_<type>(name, value) are all about parsing "value" (string
> or NULL) as <type>, return the parsed value or complain against a
> bad value for "name".  They do not care where these "name" and
> "value" come from right now, and there is no reason for them to
> start caring about caching.  They will still be the underlying
> helper functions the git_config() callbacks will depend on even
> after the second item in your list happens.

You're right of course.  For some reason I had it in my brain that these
functions retrieved *and* parsed values, as opposed to just parsing them.

I just fixed the text and pushed it live.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/