Re: [GSOC][PROPOSAL]: Refactoring in order to reduce Git’s global state
- From
Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>
- Date
- Mar 7, 2026, 12:46 UTC
- Message-ID
- <20260307125740.95052-1-shreyanshpaliwalcmsmn@gmail.com>
- In-Reply-To
- <CAP8UFD2cchYrwbhym1m9Kif7hBu3BXaK2YvOexwZT+Lcfi30LQ@mail.gmail.com>
Show 23 quoted lines
> 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.
Show 27 quoted lines
> > > 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.
Show 7 quoted lines
> > 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.
Show 12 quoted lines
> > 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.
Show 46 quoted lines
> > * 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.
Show 20 quoted lines
> > 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.
Show 9 quoted lines
> > 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.
[...]
Show 33 quoted lines
> > > > * 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.