On Tue, 13 Jan 2026 at 20:53, Junio C Hamano [off-list ref] wrote:

Olamide Caleb Bello [off-list ref] writes:

quoted

The config value `brach.autoSetupMerge` is parsed in
`git_default_branch_config()` and stored in the global variable
`git_branch_track`. This global variable can cause unexpected behaviours
when multiple Git repos run in the the same process.

Move this value into `struct repo_config_values` which holds all values
parsed by `git_default_config()` and can be accessed per
repo via `git_default_config()`. This would retain the same
behaviours while achieving repository scoped access.

Suggested-by: Phillip Wood <redacted>
Mentored-by: Christian Couder [off-list ref]
Mentored-by: Usman Akinyemi [off-list ref]
Signed-off-by: Olamide Caleb Bello <redacted>
---

Currently the code flow is for git_config(git_default_config) to be
called fairly early in the program, updating the singleton globals
that are independent from individual repository.  This moves these
global variables to be stored in the config_values structure that is
tied to the_repository.

This will move those global variables that are repository dependent into the
struct repo_config_values.
I admit the mistake is from my end. I should have been clear on that in the
commit message rather than say '...holds all variables parsed by
git_default_config()'.

Sorry

The claim in the cover letter was that this will make it possible
for us to later work on more than one repositories at once and each
repository can keep its own independent value.  While the updated
data structure may make it _possible_, I am not sure if this is a
safe approach to get to the final state, without seeing how the
config_values structure in the second "repo" structure is populated.

And before moving all these globals into config_values, it is not
possible to safely populate the config_values structure in the
second "repo" structure, if git_config(git_default_config) is what
we plan to use.  The settings that are still stored in globals will
then get overwritten.

The idea proposed by Phillip is that we pass the repository parameter
as the call back to `git_default_config()`.
But since that will be quite invasive, you proposed we use `the_repository`
for now. Then later we can pass the repository parameter as the call back
and handle the invasiveness by simply checking in git_default_config()
struct repository *r =  cb ? cb : the_repository

That is why my first question for this round of patches was "are all
these settings inherently per repository?", because the scheme would
not work if there are globals that cannot be moved to config_value
structure to be per-repo.

The movement does not target all the global variables, but only those
that are dependent on a repository.

quoted

diff --git a/repository.c b/repository.c
index c7e75215ac..d308cd78bf 100644
--- a/repository.c
+++ b/repository.c

@@ -57,6 +57,7 @@ void initialize_repository(struct repository *repo)
      ALLOC_ARRAY(repo->index, 1);
      index_state_init(repo->index, repo);
      repo->check_deprecated_config = true;
+     repo_config_values_init(&repo->config_values);

Having a call to repo_config_values_init() when initializing an
in-core repository instance is a reasonable design, and I see this
step has an initialization of git_branch_track in that function.
Shouldn't we be doing similar initialization in the same
config_values_init() function for other members of the structure,
namely, attributes_file_path and sparse_checkout?

I opted to initialize only the git_branch_track because in the original code,
it is set to a default value BRANCH_TRACK_REMOTE before the call to
git_default_config()
But attributes_file_path and sparse_checkout were only declared and
not initialized
before the call to 'git_default_config'.

I just tried to replicate the current behaviour be initializing
git_branch_track and those default
values early before the call to `git_default_config`

The function also may be a good place to do an equivalent of calling
git_config(git_default_config) there to grab values that are suitable
for the given repository, but I didn't think things through.

Thanks