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

[Shreyansh Paliwal <shreyanshpaliwalcmsmn@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?

Yup, I can gather some related links for these, will add them.

>
> > 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.

Right, got it.

> >         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.
>

Understood. I will change "Merge Commit" to "Commit" for all the patches.

> >         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.
>

Oops, I'll fix the wording.

> > * 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'.".
>

Yes, merging to next was just confirmed in the latest Mar 2026 #03,
before this it was still with a question mark and pending for any comments.
I will update the status, including for the send-email patch.

> >         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"
>

Makes sense. I'll update this.

> >         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.

[...]

> >
> > * 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!

Thanks Christian, for reading and for the suggestions, I'll revise
and send an updated version on this.