On 06/12, Jonathan Tan wrote: > On Sat, 10 Jun 2017 02:07:12 -0400 > Jeff King <peff@xxxxxxxx> 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