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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Olamide Caleb Bello <belkid98@gmail.com> writes:
>
>> -enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
>
> Unlike the other two, this global variable was not zero-initialized,
> so we can do something like this to initialize it statically in the
> new world order.  That way, we do not need to worry about the
> repo_config_values_init() helper function, which (1) we can easily
> forget to adjust, and (2) third-party may not be able to call.
>
> diff --git i/repository.c w/repository.c
> index d308cd78bf..b540e2ba01 100644
> --- i/repository.c
> +++ w/repository.c
> @@ -25,7 +25,11 @@
>  extern struct repository *the_repository;
>  
>  /* The main repository */
> -static struct repository the_repo;
> +static struct repository the_repo = {
> +	.config_values = {
> +		.branch_track = BRANCH_TRACK_REMOTE,
> +	},
> +};

After having slept over this one, I think a static initialization,
which mimicks what we have been doing with the global variables very
closely, is not what we want in the longer term.

The aim of these patches is to prepare for a new world order in
which we can add new Git subcommands that operates in two or more
repositories at the same time, and have these repositories use their
own versions of these "global" variables independently.  While the
static initialization has these advantages:

 * Once the code is written, no new command can forget to initialize
   them; initialization happens at the program load time.

 * No programming error can wipe what has already been read from the
   configuration by making a second repo_config_values_init() call
   by mistake.

neither of these advantages apply to second and subsequent
repositories.  We'd need to somehow initialize an instance of a
repository that is not "the_repo".

And for that, repo_config_values_init() is needed, even though it
adds the downsides that are opposite of the above two advantages of
not having to have an "initialization" step.

So, we need to take it as a given that repo_config_values_init()
needs to exist.  Under that condition, I wonder if we can somehow
have a cheap way to assert the following two things:

 * Before a repository instance is used, repo_config_values_init()
   has been called on it, as using an instance without initializing
   is a no-no.

 * repo_config_values_init() is never called twice on a repository
   instance, as the second call will wipe what the first call and
   subsequent reading of the configuration files have done.

Thanks.