On Mon, 5 Jan 2026 at 23:28, Junio C Hamano [off-list ref] wrote:

Phillip Wood [off-list ref] writes:

quoted

On 05/01/2026 14:23, Phillip Wood wrote:

quoted

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'

See
https://lore.kernel.org/git/d61c966b-61ae-4ba9-b983-c8dab6e2c292@gmail.com (local)
for some discussion about a possible solution.

Nice, but I suspect it would be an improvement already without
passing repository instance via git_default_config() and instead
have the code use the_repository; it is even possible not to have
any repository when the callchain executes.

Thank you Junio.
Okay, should I move the variable into the repo struct or repo-settings struct
as the case may be, then initialize it in git_default_config()?

For example
`
         if (!strcmp(var, "core.attributesfile")) {
              FREE_AND_NULL(the_repository->settings.git_attributes_file);
              return
git_config_pathname(&the_repository->settings.git_attributes_file,
var, value);
            }
`
Does this sound reasonable?

Also the `git_default_core_config()` is used to initialize the
variables to store the settings
in the "core" section of the config file.
So how about other functions like `git _default_branch_config()`,
`git _default-sparse_config()`.
Do I use the same approach above?

Thanks