[RFC] GSoC status update (config API improvements)

[RFC] GSoC status update (config API improvements)

[Tanay Abhra]

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,

	char *value;
	git_config_get_value("foo.frotz", &value);

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
on [1].

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 [2].

3> git_config() calls rewrites

Most of the git_config() calls in the code base can be rewritten as one liners using
the new config-set API.

Work has already started on it and can be seen on [3].

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 been
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. ;)

Cheers,
Tanay Abhra.

[1]:http://thread.gmane.org/gmane.comp.version-control.git/254286
[2]:http://thread.gmane.org/gmane.comp.version-control.git/254412
[3]:http://thread.gmane.org/gmane.comp.version-control.git/253948

Re: [RFC] GSoC status update (config API improvements)

[Matthieu Moy]

Tanay Abhra <tanayabh@gmail.com> writes:

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

I had totally forgotten about this, but this was the initial motivation
to write a config cache, so it would be a good conclusion for your
project.

Thanks to the patches you already wrote, the feature went from
"impossible to implement given the design" to "fairly straightforward to
implement" :-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/