From: Bello Olamide Date: Mon, 12 Jan 2026 15:05:44 GMT Subject: Re: [Outreachy PATCH RFC 1/3] environment: stop storing `core.attributesFile` globally Message-ID: In-Reply-To: On Mon, 12 Jan 2026 at 15:29, Phillip Wood wrote: > > Hi Olamide Hellp Phillip > > On 12/01/2026 12:59, Olamide Caleb Bello wrote: > > The config value parsed in git_default_core_config() is loaded eagerly > > and stored in the global variable `git_attributes_file`. > > Storing this value in a global variable can lead to unexpected > > behaviours when more than one Git repository run in the same Git process. > > > > Move this value into a `struct config_values` which holds all the values > > parsed by `git_default_config()` and can be accessed per > > repository via `git_default_config()`. This will prevent us from > > moving any code from git_default_core_config(), ensuring the current > > behaviour remains the same while also enabling the libification of Git. > > The important thing is that we're not changing when the config is > parsed, not that we're not removing code from git_default_core_config(). Okay thanks for clarifying > > Looking at the changes below, I think it would be simpler to embed > `struct config_values` in `struct repository` as we do for `struct > repo_settings`. That would simplify things as we wouldn't have to mess > about allocating an instance on the heap and freeing it in repo_clear(). Okay I will try this approach > I'd be tempted to call the new struct `repo_config` rather than > `config_values` which is rather non-specific. I initially considered `repo_config`, but a struct with the name already exists > I'm also not sure > config.[ch] is the best home for it, maybe it should live in > environment.[ch] for now - we might want to move it to it's own file at > some point. Okay this is noted. Thanks