Re: [Outreachy][Proposal]: Refactor in order to reduce Git’s global state

>
> Hello,
> This is my proposal for the project
> "Refactor in order to reduce Git’s global state" for the 2025 Outreachy
> Internship program.

> From a high level overview, environment.[ch] exposes some global
> variables that reflect a per-repository state and examples of such include
> git_work_tree_cfg, is_bare_repository_cfg, and core.* settings and functions
> which also depend on `the_repository` such as have_git_dir(),
> is_bare_repository().
> After a brief study of some related work done on the project,
> it is important to understand the purpose of the identified global variable
> and how it is used across the code base, observing how it relates with other
> subsystems and moving it to the `struct repository` or `struct
> repo-settings` if its
> use is repository specific, or specify an appropriate context based on its scope
> and use this context in the accessor functions.
> For example in [1], Patrick Steinhardt observes that `core.hooksPath`
> is repository specific and is stored in the global variable `git_hooks_path`.
> The variable is then moved into local scope in the repo-settings
> struct and a new
> accessor function `repo_settings_get_hooks_path()` is written and used to
> set the `hooks_path` of the repo specific struct which the path subsystem
> reads from.
> Similarly in [2], `core.sharedRepository` is tracked via the global variables
> `the_shared_repository ` and `need_shared_repository`. These are then
> moved into the repo-settings struct, with new accessors functions
> written to modify them,
> and calls to the accessors in the path subsystem are then modified to
> replace the old
> accessors which modify the global variables.

> 3. Review Existing Patch and Define Criteria (December 16 - January 9, 2026):
> -------------------------------------------------------------
> - Thoroughly examine the existing patch series submitted to the mailing
>     list  to understand;
>     * What criteria makes a global variable a suitable candidate to be
>        moved to the `struct repository` or `struct repo-settings`
>     * What appropriate context it should be moved into based on its
>        interactions with other subsystems.
>     * If remaining a global variable is the best approach in its case.
> - This information can be gotten by paying attention to the discussions
> in the patches and also engaging with my mentors and the Git community.