Subject: Re: [PATCH v2 00/32] repository object

From: Brandon Williams <[email-masked]>
Date: Mon, 12 Jun 2017 12:11:21 -0700

On 06/12, Jonathan Tan wrote:
> On Sat, 10 Jun 2017 02:07:12 -0400
> Jeff King <[email-masked]> wrote:
> 
> > I do agree that "pass just what the sub-function needs" is a good rule
> > of thumb. But the reason that these are globals in the first place is
> > that there are a ton of them, and they are used at the lowest levels of
> > call chains. So I have a feeling that we're always going to need some
> > big object to hold all that context when doing multi-repo operations in
> > a single process.
> 
> From my experience with the codebase, it seems that most of these config
> variables are static (file-local). This means that the lowest levels of
> call chains could probably get away with storing per-repo configs in a
> static hashmap or associative array keyed by repo (if they cannot just
> pass the config around).
> 
> Having said that, if it did come to the hashmap, I probably would prefer
> just putting the config in the repo object too. So maybe that is the way
> to go.

This is how the config is already handled.  A config_set is just a
wrapper around a fancy hashmap.  Callers query using a string as a key
and are returned the value for that config option.  I say fancy because
it does stuff to handle multiple values, etc.

I'm not sure I know what you mean by config variables which are static,
are you referring to the in-memory options which are populated by
querying the config?  Those I wouldn't want to see placed in a
'repository object'.

-- 
Brandon Williams