From: Tanay Abhra <tanayabh@gmail.com>
To: Git List <git@vger.kernel.org>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
Ramkumar Ramachandra <artagnon@gmail.com>
Subject: [RFC] GSoC status update (config API improvements)
Date: Tue, 29 Jul 2014 18:28:18 +0530 [thread overview]
Message-ID: <53D79A6A.2090302@gmail.com> (raw)
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
next reply other threads:[~2014-07-29 13:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 12:58 Tanay Abhra [this message]
2014-07-29 13:11 ` [RFC] GSoC status update (config API improvements) Matthieu Moy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D79A6A.2090302@gmail.com \
--to=tanayabh@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).