Re: [GSOC][PROPOSAL]: Refactoring in order to reduce Git’s global state

[Christian Couder <christian.couder@gmail.com>]

Hi Shreyansh,

On Fri, Mar 6, 2026 at 4:16 PM Shreyansh Paliwal
<shreyanshpaliwalcmsmn@gmail.com> wrote:
>
> Hello all,
>
> This is my first draft of GSoC 2026 proposal for the project
> 'Refactoring in order to reduce Git’s global state'.

Thanks for your interest in Git.

> I am Shreyansh Paliwal, a pre-final year undergraduate student at Guru
> Gobind Singh Indraprastha University, New Delhi, India. I am a technology
> enthusiast, who began programming in 2018 with Java as my first language
> and later transitioned to C/C++ in 2023 as my primary focus. I enjoy
> exploring new technologies and programming languages, and I have developed
> solid experience building applications using TypeScript, React.js, Node.js,
> and AWS. I actively participate in technical events and have organized
> multiple hackathons, tech-fests, and related activities at my college as
> the SIG-Head of IOSD, a tech-focused student community.

Interesting. Do you have links about these?

> Pre-GSOC:
> ---------

> During this process, I attempted to remove the usage of the_repository from
> a file. However, after discussion on the mailing list, Phillip pointed out
> that the change was not particularly useful in that context and could
> introduce segfaults that would not justify the effort for builtin code.
> Based on this feedback, I dropped that attempt and instead focused on
> understanding the broader global state refactoring effort. To better
> understand the project area, I studied previous patches and blog posts by
> Ayush Chandekar and Olamide Bello, followed discussions on the mailing
> list, and explored parts of the codebase such as the wt-status and worktree
> subsystems. This helped me understand the ongoing effort to reduce Git’s
> reliance on global state and motivated me to work further in this area.
>
> The following is a list of my contributions, ordered from earliest to most
> recent:
>
> Patches for Git:
> ----------------
>
> * test-lib-functions.sh: fix test_grep fail message wording
>         Status: Merged into master

The status should be "Released as part of v2.43.1" or something like
that as far as I can see.

>         Mailing List: https://lore.kernel.org/git/20231203171956.771-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: 37e8d795bed7b93d3f12bcdd3fbb86dfe57921e6

If you say "Merge Commit" we expect the commit that merged your work.
It looks like this commit contains your work, so I think it's better
to just say "Commit" instead.

>         Log: This was my first patch to Git in 2023. While browsing the
>                  source code and past issues, I noticed that even after
>                  the test_i18ngrep function was deprecated, an error message
>                  referring to test_grep was left behind. I updated the
>                  wording to correctly reference test_i18ngrep.

I think it should be something like:

... even after the test_i18ngrep function was deprecated, an error
message referring to test_i18ngrep was left behind. I updated the
wording to correctly reference test_grep.

> * doc: MyFirstContribution: fix missing dependencies and clarify build steps
>         Status: Merged into master
>         Mailing List: https://lore.kernel.org/git/20260112195625.391821-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: 81021871eaa8b16a892b9c8791a0c905ab26e342

Same thing about "Merge Commit" vs "Commit". Below too.

>         Log: While getting familiar with the codebase, I followed the
>                  MyFirstContribution documentation and encountered a few
>                  issues. Some include headers were missing, the synopsis
>                  format was incorrect, and the explanation for -j$(nproc)
>                  was absent. I submitted fixes to improve the clarity and
>                  correctness of the documentation.
>
> * t5500: simplify test implementation and fix git exit code suppression (Microproject)
>         Status: Merged into master
>         Mailing List: https://lore.kernel.org/git/20260121130012.888299-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: a824421d3644f39bfa8dfc75876db8ed1c7bcdbf
>         Log: This was completed as a microproject for GSoC. Instead of
>                 constructing the pack protocol using a complex combination
>                 of here-docs and echo commands, the patch captures command
>                 outputs beforehand and uses the test-tool pkt-line pack
>                 helper to construct the protocol input in a temporary file
>                 before feeding it to git upload-pack.
>
> * show-index: add warning and wrap error messages with gettext
>         Status: Merged into master
>         Mailing List: https://lore.kernel.org/git/20260130153603.290196-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: ea39808a22714b8f61b9472de7ef467ced15efea,
>                 227e2cc4e1415c4aeadceef527dd33e478ad5ec3
>         Log: While exploring the code, I noticed a TODO comment suggesting
>                 automatic hash detection. After discussion on the mailing
>                 list, it was concluded that there was no future-proof
>                 approach to implement this until a new index file format
>                 came into use. Instead, an explicit warning was added rather
>                 than silently falling back to SHA-1. Additionally, several
>                 error messages were missing gettext wrapping, which was also
>                 fixed.
>
> * wt-status: reduce reliance on global state
>         Status: Merged into seen

When a patch series isn't yet merged into next, it's better to tell
what's its status in Junio's latest "What's cooking in git.git ..."
email. For this one, it looks like it is "Will merge to 'next'.".

>         Mailing List: https://lore.kernel.org/git/20260218175654.66004-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: a7cd24de0b3b679c16ae3ee8215af06aeea1e6a3,
>                 9d0d2ba217f3ceefb0315b556f012edb598b9724,
>                 4631e22f925fa2af8d8548af97ee2215be101409
>         Log: This has been the most significant patch series in my journey
>                 so far. It began with a suggestion from Phillip to clean up
>                 some the_repository usages in wt-status.c. I extended the
>                 effort to remove all usages of the_repository and
>                 the_hash_algo from the file. During review discussions, it
>                 was suggested that some worktree API cleanup should happen
>                 first, particularly regarding the representation of worktrees
>                 as NULL. Some related changes were later moved to a separate
>                 series, after which this refactoring proceeded.
>
> * worktree: change representation and usage of primary worktree
>         Status: Continued by Phillip Wood [1]

Here you can also say that they have been merged into master. Maybe:
"Status: Merged into master after being continued by Phillip Wood"

>         Mailing List: https://lore.kernel.org/git/20260213120529.15475-1-shreyanshpaliwalcmsmn@gmail.com/
>         Log: This worktree API cleanup series started while I was working
>                 on wt-status. The intention was to modify the representation
>                 of the current worktree so that struct worktree would not be
>                 NULL. During discussion, Phillip clarified that NULL actually
>                 represents the current worktree rather than the primary
>                 worktree. Since Phillip already had a patch based on the right
>                 logic, he continued the series and it was eventually merged
>                 into master.
>
> * tree-diff: remove the usage of the_hash_algo global
>         Status: Merged into master
>         Mailing List: https://lore.kernel.org/git/20260220175331.1250726-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: 1e50d839f8592daf364778298a61670c4b998654
>         Log: This was a straightforward patch that removed the remaining
>                 usages of the global the_hash_algo in tree-diff.c by using the
>                 repository’s local instance instead.
>
> * send-email: UTF-8 encoding in subject line
>         Status: Merged into seen
>         Mailing List: https://lore.kernel.org/git/20260228112210.270273-1-shreyanshpaliwalcmsmn@gmail.com/
>         Merge Commit: c52f085a477c8eece87821c5bbc035e5a900eb12
>         Log: This patch was motivated by an issue I personally encountered
>                 while sending a GSoC discussion email [2]. Initially the
>                 change only modified the wording of the prompt, but after
>                 discussion on the mailing list it was extended to include
>                 proper validation to prevent invalid charset encodings from
>                 being used in git send-email and to reduce confusion.
>
> * Remove global state from editor.c
>         Status: Waiting for further feedback
>         Mailing List: https://lore.kernel.org/git/20260301105228.1738388-1-shreyanshpaliwalcmsmn@gmail.com/
>         Log: This was based on my doubt on localizing editor_program in
>                 editor.c [2]. The patch received mixed feedback from
>                 contributors and is currently awaiting additional guidance
>                 from mentor and/or maintainer regarding the appropriate
>                 direction.
>
> Patches for git.github.io:
> --------------------------
>
> * SoC-2026-ideas: Remove an extra backtick
>         Status: merged into master
>         PR Link: https://github.com/git/git.github.io/pull/831
>         Merge Commit: c1e4aa87a54430953eaa7355061139fdf1ff6796
>         Log: Minor Typo fix.
>
> * rn-132: fixed 2 typos
>         Status: merged into master
>         PR Link: https://github.com/git/git.github.io/pull/832
>         Merge Commit: 92876114d855d472ce2e0e5337e72a4b97b81681
>         Log: Fixed typos in Git Rev News Edition 132.
>
> I have also been involved in additional discussions on the Git mailing
> list [3][4][5][6].

[...]

> Project Timeline:
> ----------------
>
> * Community Bonding (Until May 24):
>         - Discuss the project direction and design approaches with mentors.
>         - Identify and prioritize two main areas of work:
>                 + files that rely on the_repository.
>                 + global variables defined in environment.c.
>         - Study the previous patches by Olamide Bello and Ayush in depth and
>                  also discuss with them about their approaches and challenges.
>         - Interact with all the people involved in this work to better
>                  understand design decisions and potential pitfalls.
>         - Experiment with small RFC patches, if needed to validate approaches.
>
> * Coding period (May 25 - August 16):
>         - Review the work done by Olamide Bello on moving values parsed by
>                  git_default_config() into the repo_config_values structure and
>                  identify any remaining tasks.

I think this should be part of the Community Bonding period.

>         - Complete remaining cleanup or refactoring related to the worktree API,
>                  if left any [19].
>         - Identify straightforward refactors to remove usages of the_repository
>                  in files such as xdiff-interface.c, archive*.c, fsmonitor*.c etc.
>         - Work file by file with the goal of eliminating
>                  #define USE_THE_REPOSITORY_VARIABLE by replacing global usages
>                  with explicit repository instances.
>         - Concurrently maintain at least two parallel patch series:
>                 + Small / straightforward refactors and replacements like
>                          the_hash_algo or the_repostitory.
>                 + Larger structural refactors involving globals such as
>                          DEFAULT_ABBREV, comment_line_str etc.
>         - Publish weekly or biweekly blog updates documenting progress and design
>                  decisions.
>
> * Final week (august 17 - august 24):
>         - Address any remaining tasks or pending patches.
>         - Recieve final feedback from mentors and reviewers.

s/Recieve/Receive/

>         - Prepare a detailed report summarizing the work completed during the project.


Thanks for your proposal!