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