Hi,

On Wed, Oct 29, 2025 at 2:18 AM Bello Olamide [off-list ref] wrote:

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

Thanks for this proposal.

[...]

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.

Nit: the above paragraph looks very big. Maybe it could be split a bit.

I also studied [3], [4] by Ayush Chandeker,] and [5] by John Cai to broaden my
understanding of the project.

Are there some cases where strategies other than writing new accessors
functions were used?

Are there pieces of work on this that were started but not finished?
Are you planning to finish them?

What are the roadblocks that were faced when working on this?

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.

Are you sure that it will be possible to define clear criteria?

Thanks.