One month to go for GSoC to end and I am almost at the end of my project.
So what have we accomplished do far? Let's see,
1> Git config cache:
I have written a config cache which reads and caches the key/value pairs
in a hashmap. It is generalized as config-set which can also be used to read
config-like files (for example submodule config files).
Instead of the unwieldy git_config() callback process for querying, callers
can now use the new API to query config values in as straightforward manner.
for example, for querying "foo.frotz", we can just write,
Similar to git_config_get_value() there are helpers which do conversion to the
desired type (int or bool) as well as querying.
It is already in pu as "ta/config-set" and its latest iteration can be found
2> git_config() now uses the caching layer underneath.
git_config() now uses the config-set API, thus preventing expensive rereads
of the configuration files during a git invocation.
It's almost polished and ready for pu. The latest iteration can be found on .
3> git_config() calls rewrites
Most of the git_config() calls in the code base can be rewritten as one liners
the new config-set API.
Work has already started on it and can be seen on .
4> Tidy git configuration files
To be honest, I haven't started any real work on it, except brainstorming on it
for a little while. Basically it aims to correct the two broken tests in
t1300-repo-config.sh, caused by the deficiencies in git_config_set() which are,
section headers are left untouched, even when all the keys related to it have
unset and adding a key into an empty section reuses the header .
5> Any new feature suggestions??
Other than the above, new features can be built on top of the new API.
Going through the previous mailing lists I could find one or two ideas, namely,
a> Unsetting previously set values
Local config files can be used to unset config values previously set in system
files. The user may not have the privilege to touch the system files so he can
leverage the new API to unset the previously set values.
Any suggestions for new features or improvements are welcome!
Also, I like to thank my mentors Matthieu and Ram for their suggestions
and timely review even when my patches were late. ;)
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