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

[Bello Olamide <belkid98@gmail.com>]

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

Personal Bio:
===========
Full Name: Bello Caleb Olamide
Email: belkid98@gmail.com
Personal Blog: https://cloobtech.hashnode.dev/
GitHub: https://github.com/cloobtech

About Me:
=========
I'm Bello Olamide. I am passionate about software engineering and
I love to figure out things. I like participating in tech
events such as hackathons but this will be my first open source experience
and I have relished the opportunity and experience so far.
I love being part of a community that strive to achieve a goal and one that
I found myself is a small albeit growing community that helps to guide and
mentor younger boys find their way into the tech ecosystem. I have developed
my coding skill via various sources including personal learning, freelancing,
collaboration with other developers and from the ALX Software Engineering
program.

Past Experience with Git:
===================
I have been a Git user for sometime now majorly for collaborating with other
developers, tracking version changes to files and during this contribution
stage, I have understood the ropes of how to send patches to Git.

Contributions to the Git Community:
==========================
I have been able to send some patches to the Git codebase with the guidance
and direction of community members.

Microproject:
==========
Link: https://lore.kernel.org/git/cover.1761217100.git.belkid98@gmail.com/
Branch: ob/gpg-interface-cleanup
Status: Merged to next
Commit ID: ce6d041635
Description: strbuf_split*() to split a string into multiple strbufs
is often a wrong API to use.
A few uses of it have been removed by simplifying the code.

Project Overview
=============
Git uses a single global `struct repository` object called `the_repository`
which internal functions rely on to store, access and modify environment
and configuration variables.
With this approach, multi-repository instances running in the same process
can lead to inconsistent behaviours and race conditions.
By refactoring the code to stop storing repository-scoped
configurations in global variables in
`environment.c file`, that is by moving the appropriate global
variables into localised state
within the `struct repository` and `struct repo-settings`, the
codebase becomes more maintainable,
easier to test and future work such as libifying Git becomes feasible.

Internship Objectives and Plans
========================
The project aims to identify repository scoped global variables in
`environment.c`
and related files that can be moved to local scope within `struct
repository` and
`struct repo-settings`, find an appropriate strategy to move them to
local scope and implement the changes. This architectural improvement
will make the
codebase more maintainable and enable better multi-repository handling
in the future.

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.

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

Proposed Project Execution Timeline
=========================

1. Study Code Base To Identify Suitable Candidates (Now - December 8, 2025):
------------------------------------------------------------------------
- The first step will be familiarising myself with the code base to
   understand how these global variables in environment.c are initialised,
   used and how they interact with other subsystems.

2. Community Feedback Bonding ( December 9 - December 15, 2025):
------------------------------------------------------------
- Discuss environment variables with mentors and community members
- Understand best refactoring approach based on feedback from mentors

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.

4. Implement Candidates and Submit PRs ( January 10 - February 28, 2026):
--------------------------------------------------------------------------
- With collaboration from mentors and the Git community, identify
suitable candidates for relocation.
- Relocate them into `struct repository`, `struct repo-settings` and
other appropriate
contexts.
- Pass the repository parameter to accessor functions to replace the
global dependence
- Write new accessor functions if necessary
- Modify accessor callers to reflect the new changes while ensuring
all affected code paths works
  correctly
- Update tests and documentations
- Recursively submit patches for reviews, engaging in discussions and
implement suggestions

5. Final Report on Project (February 29 - March 6)
--------------------------------
- Document final report in my blog with details on my experience
- Finalize any pending tasks or reviews on any submitted patch

Availability
========
I am currently not enrolled in any school or jobs, so I will be able to give
30 hours a week or more to make the project a success.

Blogging
=======
I have set up my blog where i will document my progress, insights,
challenges and experience weekly.

Post Outreachy
====================
The welcoming and patient atmosphere during this short contribution
period with the Git
community has made me want to keep getting involved with the
community. I am committed to
continuously contributing to Git and become a part of of the next set
of contributors
to champion the continuous development of Git.

Appreciation
==========
To Junio and Christian, I really appreciate your guidance, patience
and direction while
reviewing and helping with my patches and to Usman for your inputs and to every
member of the Git community, I thank you all.

References
=========
[1]: https://public-inbox.org/git/20250207-b4-pks-path-drop-the-repository-v2-14-13cad3c11b8a@pks.im/#Z31config.c
[2]: https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-15-4e77f0313206@pks.im/
[3]: https://lore.kernel.org/git/d0e2042b3061320fac8a8fdf9043c6ab4dbed5a2.1752882401.git.ayu.chandekar@gmail.com/
[4]: https://lore.kernel.org/git/c82620a1f54ea6760bff204fd2b5fe5c2df1896c.1753804956.git.ayu.chandekar@gmail.com/
[5]: https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/