Re: [Outreachy PATCH v2 3/3] environment: move "branch.autoSetupMerge" into `struct repo_config_values`

From: Bello Olamide <belkid98@gmail.com>
Date: Jan 14, 2026, 07:40 UTC
Message-ID: <CAD=f0L-mPX+KECUjXk-WBzEbTP7wCa8sB56GySQT0yh9mfUOWw@mail.gmail.com>
In-Reply-To: <xmqqo6mxi91e.fsf@gitster.g>

On Tue, 13 Jan 2026 at 20:53, Junio C Hamano <gitster@pobox.com> wrote:

Show 24 quoted lines

>
> Olamide Caleb Bello <belkid98@gmail.com> writes:
>
> > 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 <phillip.wood123@gmail.com>
> > Mentored-by: Christian Couder <christian.couder@gmail.com>
> > Mentored-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
> > Signed-off-by: Olamide Caleb Bello <belkid98@gmail.com>
> > ---
>
> 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

Show 13 quoted lines

>
> 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

Show 5 quoted lines

>
> 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.

Show 18 quoted lines

>
>
> > 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`

Show 5 quoted lines

>
> 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