On 03/06/2014 08:24 PM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>> I just wrote up the idea that fell out of the discussion  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
>> ; the text is also appended below for your convenience.
>>  http://article.gmane.org/gmane.comp.version-control.git/242952
>>  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
> Are you sure about the second sentence of this item is what you
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html