Re: [GSoC][Draft Proposal v4] Refactoring in order to reduce Git's global state
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Feb 27, 2026, 09:03 UTC
- 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
Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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