Re: StGIT and repo-config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27/01/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
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.

> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]