All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: git discussion list <git@vger.kernel.org>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: RFC GSoC idea: git configuration caching (needs co-mentor!)
Date: Thu, 06 Mar 2014 06:57:20 +0100	[thread overview]
Message-ID: <53180E40.5050308@alum.mit.edu> (raw)

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.

* Rewrite callers to use the new API wherever possible.

You will need to consider how to handle other config API entry points
like `git_config_early()` and `git_config_from_file()`, as well as how
to invalidate the cache correctly in the case that the configuration
is changed while `git` is executing.

See
[this mailing list
thread](http://article.gmane.org/gmane.comp.version-control.git/242952)
for some discussion about this and related ideas.

 - Language: C
 - Difficulty: medium
 - Possible mentors: Michael Haggerty

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

             reply	other threads:[~2014-03-06  5:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  5:57 Michael Haggerty [this message]
2014-03-06 19:24 ` RFC GSoC idea: git configuration caching (needs co-mentor!) Junio C Hamano
2014-03-06 19:46   ` Jeff King
2014-03-06 21:33   ` Michael Haggerty

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=53180E40.5050308@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.