Re: StGIT and repo-config

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jan 28, 2007, 23:30 UTC
Message-ID: <b0943d9e0701281530x791078ebk78070252251323a4@mail.gmail.com>
In-Reply-To: <20070127103354.GE4036@nan92-1-81-57-214-146.fbx.proxad.net>

On 27/01/07, Yann Dirson <ydirson@altern.org> wrote:

Show 9 quoted lines

> On Sat, Jan 27, 2007 at 12:12:36AM +0100, Johannes Schindelin wrote:
> > Well, we have only two multi-valued keys at the moment (AFAIK):
> > remote.<branch>.fetch and remove.<branch>.push.
> >
> > Even if there are more, they are hardly interesting to StGIT, right?
>
> Not completely right.  It is precisely remote.<branch>.fetch I'm
> needing, to be able to locate which remote a parent branch belongs to
> when creating a stack.

You could have a dictionary with list of values instead of just one overriding the former. The config object can have 2 methods - get_option(), returning config_dict[option][-1] (i.e. always the last, most specific option) and get_moption() returning the whole list. The code requiring the options should know which method to call for either getting a single value or multiple values.

Show 5 quoted lines

> > The point is: it is very easy and short to just stash everything into a
> > dictionary, and retrieve it from there.
>
> OTOH, it is equally easy (if not easier) to call "git repo-config
> --get" or --get-all when needed :)

It is possible that we'll end up calling it too many times when working on huge series (a very good benchmark is the -mm kernel series, it really shows performance bottlenecks, mainly caused by GIT operations for writing the index).

You could also cache the values only when asked for an option the first time but given the relatively small size the config files, there isn't any performance impact in caching all the options at once.

-- 
Catalin