From: Phillip Wood <phillip.wood123@gmail.com>
Date: Fri, 27 Feb 2026 09:03:46 GMT
Subject: Re: [GSoC][Draft Proposal v4] Refactoring in order to reduce Git's global state
Message-ID: <1d43d1d0-bf6b-4806-834e-89f545fab766@gmail.com>
In-Reply-To: <5e5f07ec-72ba-46ee-812c-d6773a4bdbe7@gmail.com>

Hi Tian

On 26/02/2026 17:02, Tian Yuchen wrote:
> [...]
> Although the principle is simple, the scope of changes is extensive. The
> following three-step approach can serve as a guiding principle for it:

There are four steps below

>    1. Identify isolated environment variables currently residing in the
>       global scope. Conduct a case-by-case analysis to map each variable
>       to its most appropriate existing home (e.g., struct repo_settings
>       for configuration values, or specific localized structs within
>       struct repository).

Note that as settings in struct repo_settings are lazily parsed, it is 
only suitable for settings that are already lazily parsed. That means it 
is not a suitable home for any settings that are parsed at startup by 
git_default_config().

>    2. Instead of blindly passing struct repository *repo down into every
>       single low-level library function, bubbling the dependency up is
>       the true goal. External callers of the functions must be carefully
>       audited to prevent regressions.

Where a function only needs one piece of information from struct 
repository that sounds like a good strategy.

>    3. Safely remove the old global variables and macro definitions. Make
>       full use of Git's existing GitLab/GitHub CI and utilize local
>       Meson builds with AddressSanitizer enabled to ensure that the new
>       lifecycle introduces zero memory leaks.
>    4. Many globals like `editor_program` are parsed once and remain
>       available globally. New data flow might need to be designed to
>       maintain the lazy-loading efficiency.

Although `editor_program` is parsed once, that happens in 
git_default_config() so it is not lazily loaded and making it lazily 
loaded would be a regression as if the config value is invalid we want 
to exit with an error early in the process, not just before we prompt 
the user to edit a file.

Thanks

Phillip