Re: [Outreachy PATCH v2] environment: move "core.attributesFile" into repo-setting

>
> Hi Olamide
>
> On 02/01/2026 16:32, Olamide Caleb Bello wrote:
> > When handling multiple repositories within the same process, relying on
> > global state for accessing the "core.attributesFile" configuration can
> > lead to incorrect values being used. It also makes it harder to isolate
> > repositories and hinders the libification of git.
> > The functions `bootstrap_attr_stack()` and `git_attr_val_system()`
> > retrieve "core.attributesFile" via `git_attr_global_file()`
> > which reads from global state `git_attributes_file`.
> >
> > Move the "core.attributesFile" configuration into the
> > `struct repo_settings` instead of relying on the global state.
>
> This changes when the config setting gets parsed which unfortunately
> regresses the user experience when the setting is invalid.
>
> If I run 'git -c core.attributesFile=~does-not-exist rebase -i' with git
> built from master it fails immediately with "fatal: failed to expand
> user dir in: '~does-not-exist'". With this patch applied it prompts me
> to edit the todo list and then fails when it tries to checkout the
> commit we're rebasing onto. Because "git rebase" expects reset_head() to
> return an error rather die if the checkout fails it is left in a strange
> state where only practical course of action for the user is to run "git
> rebase --abort".

>
> It is quite common that moving from parsing config settings eagerly by
> calling repo_config() at startup to parsing them lazily via 'stuct
> repo_settings' causes regressions like this. We really should find a way
> to address that before moving more settings into 'struct repo_settings'
>