{"thread":{"id":"65152","subject":"[GSOC][PROPOSAL]: Refactoring in order to reduce Git’s global state","startedAt":"2026-03-06T15:16:59Z","lastAt":"2026-03-20T18:17:38Z","messageCount":7,"participants":["Shreyansh Paliwal","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"538086","messageId":"20260306151605.29330-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65152","inReplyTo":null,"subject":"[GSOC][PROPOSAL]: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-03-06T14:57:33Z","receivedAt":"2026-03-06T15:16:59Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"Hello all,\n\nThis is my first draft of GSoC 2026 proposal for the project\n'Refactoring in order to reduce Git’s global state'.\n\nDoc version can be read at:\nhttps://docs.google.com/document/d/16MRNUv6dJi6vtNvI5Ro0WmHf20dRRBHjFLpmhAuaUOA/edit?usp=sharing\n\nAny feedback or suggestions would be greatly appreciated.\n\nThanks for reading.\n---\n\nRefactoring in order to reduce Git's global state\n\nPersonal Information:\n---------------------\n\nName: Shreyansh Paliwal\nEmail: Shreyanshpaliwalcmsmn@gmail.com\nAlternate Email: Shreyansh.01014803123@it.mait.ac.in\nMobile No.: +91-9335120023\n\nEducation: GGSIPU, New Delhi, India\nYear: III / IV\nDegree: Bachelor of Technology in Information Technology\n\nGithub: https://github.com/shreyp135\nTime-zone: UTC +5:30 (IST)\n\nAbout Me:\n---------\n\nI am Shreyansh Paliwal, a pre-final year undergraduate student at Guru\nGobind Singh Indraprastha University, New Delhi, India. I am a technology\nenthusiast, who began programming in 2018 with Java as my first language\nand later transitioned to C/C++ in 2023 as my primary focus. I enjoy\nexploring new technologies and programming languages, and I have developed\nsolid experience building applications using TypeScript, React.js, Node.js,\nand AWS. I actively participate in technical events and have organized\nmultiple hackathons, tech-fests, and related activities at my college as\nthe SIG-Head of IOSD, a tech-focused student community.\n\nI started using Git in 2023, which is also when I made my first open-source\ncontribution to the Git project. I was a winner of Augtoberfest 2024, an\nopen-source competition organized by C4GT India. Over the past several\nmonths, I have been involved with the Git project, studying the codebase,\nsubmitting patches, and incorporating review feedback. I am motivated to\nimprove the experience of Git for end users, and this project is an\nexcellent opportunity to continue that work.\n\nOverview:\n---------\n\nGit relies heavily on global state for managing environment variables and\nconfiguration data. In particular, many parts of the codebase depend on the\nglobal struct repository instance, the_repository, which represents the\ncurrently active repository. Instead of passing a repository instance\nexplicitly, several internal functions implicitly rely on this global\nobject. Additionally, various configuration derived values and\nenvironment-related variables such as the_hash_algo, default_abbrev, and\ncomment_line_str are stored globally, most of them defined in\nenvironment.c.\n\nThis design assumes that only one repository is active within a process at\na time. As a result, the repository state becomes shared across the entire\nprocess, weakening isolation and making behavior implicitly dependent on\nglobal context. Such global dependencies make the code harder to reason\nabout, test, and maintain, and can introduce subtle bugs when operations\ninteract with multiple repositories. They also limit long-term goals such\nas safely supporting multiple repositories within a single process and\ncontinuing Git’s ongoing libification efforts.\n\nTo address these issues, global environment and configuration state should\nbe refactored into better-scoped contexts. Repository-specific data can be\nmoved into struct repository or related structures, while\nsubsystem-specific state should be localized appropriately. Passing\nrepository instances explicitly through function interfaces will improve\nmodularity, reduce hidden dependencies, and make the codebase easier to\nmaintain while moving Git closer to supporting multiple repositories safely\nwithin a single process.\n\nThe difficulty of this project is medium, and it is estimated to take 175\nto 350 hours.\n\nPre-GSOC:\n---------\n\nI first explored the Git codebase in December 2023, when I submitted a\nsmall patch fixing the wording of an error message that I noticed while\nbrowsing the source code. At that time I had recently started using Git and\nGitHub for version control in my projects, which sparked my curiosity about\nhow Git works internally.\n\nA few months ago, when I had some free time from college, I decided to\nstart contributing to Git more actively. I built Git from source, read\nparts of the documentation, and familiarized myself with the mailing list\nworkflow. While going through the documentation, I noticed a few\ninconsistencies in the MyFirstContribution page and submitted patches to\nfix them. I also completed a microproject involving a test cleanup, and\nlater worked on adding a warning for a quiet fallback.\n\nDuring this process, I attempted to remove the usage of the_repository from\na file. However, after discussion on the mailing list, Phillip pointed out\nthat the change was not particularly useful in that context and could\nintroduce segfaults that would not justify the effort for builtin code.\nBased on this feedback, I dropped that attempt and instead focused on\nunderstanding the broader global state refactoring effort. To better\nunderstand the project area, I studied previous patches and blog posts by\nAyush Chandekar and Olamide Bello, followed discussions on the mailing\nlist, and explored parts of the codebase such as the wt-status and worktree\nsubsystems. This helped me understand the ongoing effort to reduce Git’s\nreliance on global state and motivated me to work further in this area.\n\nThe following is a list of my contributions, ordered from earliest to most\nrecent:\n\nPatches for Git:\n----------------\n\n* test-lib-functions.sh: fix test_grep fail message wording\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20231203171956.771-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: 37e8d795bed7b93d3f12bcdd3fbb86dfe57921e6\n Log: This was my first patch to Git in 2023. While browsing the\n source code and past issues, I noticed that even after\n the test_i18ngrep function was deprecated, an error message\n referring to test_grep was left behind. I updated the\n wording to correctly reference test_i18ngrep.\n\n* doc: MyFirstContribution: fix missing dependencies and clarify build steps\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260112195625.391821-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: 81021871eaa8b16a892b9c8791a0c905ab26e342\n Log: While getting familiar with the codebase, I followed the\n MyFirstContribution documentation and encountered a few\n issues. Some include headers were missing, the synopsis\n format was incorrect, and the explanation for -j$(nproc)\n was absent. I submitted fixes to improve the clarity and\n correctness of the documentation.\n\n* t5500: simplify test implementation and fix git exit code suppression (Microproject)\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260121130012.888299-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: a824421d3644f39bfa8dfc75876db8ed1c7bcdbf\n Log: This was completed as a microproject for GSoC. Instead of \n constructing the pack protocol using a complex combination\n of here-docs and echo commands, the patch captures command\n outputs beforehand and uses the test-tool pkt-line pack\n helper to construct the protocol input in a temporary file\n before feeding it to git upload-pack.\n\n* show-index: add warning and wrap error messages with gettext\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260130153603.290196-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: ea39808a22714b8f61b9472de7ef467ced15efea,\n 227e2cc4e1415c4aeadceef527dd33e478ad5ec3\n Log: While exploring the code, I noticed a TODO comment suggesting\n automatic hash detection. After discussion on the mailing\n list, it was concluded that there was no future-proof\n approach to implement this until a new index file format\n came into use. Instead, an explicit warning was added rather\n than silently falling back to SHA-1. Additionally, several\n error messages were missing gettext wrapping, which was also\n fixed.\n\n* wt-status: reduce reliance on global state\n Status: Merged into seen\n Mailing List: https://lore.kernel.org/git/20260218175654.66004-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: a7cd24de0b3b679c16ae3ee8215af06aeea1e6a3,\n 9d0d2ba217f3ceefb0315b556f012edb598b9724,\n 4631e22f925fa2af8d8548af97ee2215be101409\n Log: This has been the most significant patch series in my journey\n so far. It began with a suggestion from Phillip to clean up\n some the_repository usages in wt-status.c. I extended the\n effort to remove all usages of the_repository and\n the_hash_algo from the file. During review discussions, it\n was suggested that some worktree API cleanup should happen\n first, particularly regarding the representation of worktrees\n as NULL. Some related changes were later moved to a separate\n series, after which this refactoring proceeded.\n\n* worktree: change representation and usage of primary worktree\n Status: Continued by Phillip Wood [1]\n Mailing List: https://lore.kernel.org/git/20260213120529.15475-1-shreyanshpaliwalcmsmn@gmail.com/\n Log: This worktree API cleanup series started while I was working\n on wt-status. The intention was to modify the representation\n of the current worktree so that struct worktree would not be\n NULL. During discussion, Phillip clarified that NULL actually\n represents the current worktree rather than the primary\n worktree. Since Phillip already had a patch based on the right\n logic, he continued the series and it was eventually merged\n into master.\n\n* tree-diff: remove the usage of the_hash_algo global\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260220175331.1250726-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: 1e50d839f8592daf364778298a61670c4b998654\n Log: This was a straightforward patch that removed the remaining\n usages of the global the_hash_algo in tree-diff.c by using the\n repository’s local instance instead.\n\n* send-email: UTF-8 encoding in subject line\n Status: Merged into seen\n Mailing List: https://lore.kernel.org/git/20260228112210.270273-1-shreyanshpaliwalcmsmn@gmail.com/\n Merge Commit: c52f085a477c8eece87821c5bbc035e5a900eb12\n Log: This patch was motivated by an issue I personally encountered\n while sending a GSoC discussion email [2]. Initially the\n change only modified the wording of the prompt, but after\n discussion on the mailing list it was extended to include\n proper validation to prevent invalid charset encodings from\n being used in git send-email and to reduce confusion.\n\n* Remove global state from editor.c\n Status: Waiting for further feedback\n Mailing List: https://lore.kernel.org/git/20260301105228.1738388-1-shreyanshpaliwalcmsmn@gmail.com/\n Log: This was based on my doubt on localizing editor_program in\n editor.c [2]. The patch received mixed feedback from\n contributors and is currently awaiting additional guidance\n from mentor and/or maintainer regarding the appropriate\n direction.\n\nPatches for git.github.io:\n--------------------------\n\n* SoC-2026-ideas: Remove an extra backtick\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/831\n Merge Commit: c1e4aa87a54430953eaa7355061139fdf1ff6796\n Log: Minor Typo fix.\n\n* rn-132: fixed 2 typos\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/832\n Merge Commit: 92876114d855d472ce2e0e5337e72a4b97b81681\n Log: Fixed typos in Git Rev News Edition 132.\n\nI have also been involved in additional discussions on the Git mailing\nlist [3][4][5][6].\n\nHistory / Background:\n--------------------\n\nEfforts to reduce Git’s reliance on global state started when several Git\nsubsystems began moving toward libification, where Git’s internal\nfunctionality could be reused as a library. Early examples of this\ndirection include major patch series such as the libification of git\nmailinfo by Junio [7] and git apply by Christian [8]. These large patch\nseries exposed the limitations of relying on process-wide global state and\nhighlighted the need for better encapsulation of repository-related data.\n\nOne important step in this direction was the introduction of struct\nrepository, through refactoring work by Stefan Beller [9] and Brandon\nWilliams [10]. The motivation behind this structure was to centralize\nrepository-related state instead of relying on scattered global variables.\nThis change improved code clarity and made it easier to reason about Git’s\ninternal behavior. It also laid the groundwork for future improvements such\nas safer multithreading and the possibility of handling submodules within\nthe same process. Later, additional refactoring work by Patrick further\nremoved reliance on the global the_repository in config [11] and path [12]\nsubsystems. As part of this work, several variables were consolidated into\nenvironment.c from config.c so that environment-related state could be\nmanaged in a single location [13]. The macro #define\nUSE_THE_REPOSITORY_VARIABLE was also introduced to help transition code\naway from implicit global repository access [14].\n\nThis project area was further explored during GSoC 2025 by Ayush Chandekar\n[15], who continued removing usages of the_repository across different parts\nof the codebase and relocated several global configuration variables (such as\ncore_preload_index and merge_log_config) into repository-scoped structures.\nMore recently, Olamide Bello, during the Outreachy program, made significant\nprogress in improving how configuration values are stored [16] [17]. His work\nintroduced a new structure, repo_config_values, which stores repository\nspecific configuration values, linked to struct repository. This allows\nconfiguration values to be associated with a specific repository instance\nrather than stored globally. Along with this, a private structure\nconfig_values_private was added to support initialization and internal\nhandling of these values. During discussions around these changes, an\nimportant design consideration also emerged, moving global variables directly\ninto repository structures or introducing lazy loading helpers can lead to\nuser experience regressions if configuration errors are detected later.\n\nThese efforts collectively form the foundation of the ongoing work to\ngradually remove Git’s reliance on global state and move toward a more\nmodular, repository-scoped architecture.\n\nProposed Plan:\n-------------\n\nI started exploring the codebase by browsing relevant files and identifying\nglobal variables by temporarily removing the USE_THE_REPOSITORY_VARIABLE\nmacro. My primary focus was on core library files rather than builtin code\n[18]. Through this exploration, I observed that a large number of files still\ndepend on the_repository.\n\nTo tackle this project systematically, I propose classifying these files into\ntwo categories:\n\n1. Files using the_repository or the_hash_algo where a repository instance\n already exists: These files rely on global variables even though a\n struct repository instance is available somewhere in the call stack. In\n such cases, the refactor primarily involves passing the repository\n instance through the function call stack and replacing the global\n usages. In some cases, a repository instance may not be directly\n available in the file itself. In those situations, I will trace the\n callers and propagate repository instances from higher levels in the call\n hierarchy. Examples of such files include, alias.c, archive*.c,\n walker.c, xdiff-interface.c. These cases generally require localized\n refactoring and are good candidates for incremental patches.\n\n2. Files relying on other global variables defined in environment.c: Some\n files rely on additional global variables which are parsed and accessed\n through environment.c. In these cases, there is no existing\n repository-scoped instance, which makes refactoring slightly more\n technical. Examples include, wt-status.c (default_abbrev,\n comment_line_str), apply.c (has_symlink, ignore_case,\n trust_executable_bit, apply_default_whitespace,\n apply_default_ignorewhitespace). For such variables, I plan to evaluate\n whether they should be moved into a repository-scoped structure (e.g.,\n repo_settings, repo_config_values), or they should instead be localized\n and passed explicitly where needed. The appropriate approach will depend\n on how widely the variable is used and whether it logically fits in the\n multi-repository standpoint.\n\nI plan to begin with the first category, addressing straightforward\nrefactors file by file. In parallel, I will analyze and work on specific\ngroups of global variables from the second category, designing appropriate\nrepository-scoped replacements.\n\nThe end goal is to remove reliance on global state and eventually eliminate\nthe USE_THE_REPOSITORY_VARIABLE macro from these files.\n\nProject Timeline:\n----------------\n\n* Community Bonding (Until May 24):\n - Discuss the project direction and design approaches with mentors.\n - Identify and prioritize two main areas of work:\n + files that rely on the_repository.\n + global variables defined in environment.c.\n - Study the previous patches by Olamide Bello and Ayush in depth and\n also discuss with them about their approaches and challenges.\n - Interact with all the people involved in this work to better\n understand design decisions and potential pitfalls.\n - Experiment with small RFC patches, if needed to validate approaches.\n\n* Coding period (May 25 - August 16):\n - Review the work done by Olamide Bello on moving values parsed by\n git_default_config() into the repo_config_values structure and\n identify any remaining tasks.\n - Complete remaining cleanup or refactoring related to the worktree API,\n if left any [19].\n - Identify straightforward refactors to remove usages of the_repository\n in files such as xdiff-interface.c, archive*.c, fsmonitor*.c etc.\n - Work file by file with the goal of eliminating\n #define USE_THE_REPOSITORY_VARIABLE by replacing global usages\n with explicit repository instances.\n - Concurrently maintain at least two parallel patch series:\n + Small / straightforward refactors and replacements like\n the_hash_algo or the_repostitory.\n + Larger structural refactors involving globals such as\n DEFAULT_ABBREV, comment_line_str etc.\n - Publish weekly or biweekly blog updates documenting progress and design\n decisions.\n\n* Final week (august 17 - august 24):\n - Address any remaining tasks or pending patches.\n - Recieve final feedback from mentors and reviewers.\n - Prepare a detailed report summarizing the work completed during the project.\n\nBlogging:\n---------\n\nI believe blogging is an important part of any open-source project. It\nhelps others understand the ongoing work and also enables the contributor\nto develop a deeper understanding and keep a better track of their own\nprogress. I experienced this firsthand, early in my journey I was unsure\nabout various aspects, but reading the blogs of Ayush and Olamide Bello\ngave me valuable insight into the contributor perspective and their overall\nwork.\n\nWith the goal of helping future contributors in a similar way, I plan to\ndocument my journey and project progress through regular blog posts. I will\npublish updates on a weekly or biweekly basis, depending on the amount of\nmeaningful progress made. I have set up my blogging area on Medium, and my\nposts will be available at [20].\n\n\nAvailability:\n-------------\n\nThe main coding period runs from June to August. Most of June and July\ncoincide with my summer vacation, which allows me to dedicate significant\ntime to the project. My final exams are scheduled for May and will last\napproximately one week, but they will be completed before the coding period\nbegins and should not affect my availability.\n\nDuring June and July, I will be able to dedicate around 40 hours per week to\nthe project. In August, when my regular semester resumes, I expect to\ncontribute approximately 25–30 hours per week.\n\nI do not have any other exams, internships, or planned vacations during the\ncoding period. Apart from this project, I have no other major commitments\nfor the summer.\n\nI will keep the community regularly updated on my progress throughout the\nproject. My primary mode of communication will be email, and I will also be\navailable for calls or meetings if/when required. My preferred availability\nwindow is 13:00–19:00 UTC.\n\nPost GSoC:\n----------\n\nBeing part of the Git community and contributing to the codebase has been a\nvery valuable experience for me. The process of understanding Git’s internals,\nsubmitting patches, and receiving feedback on the mailing list has helped me\ngrow significantly as a developer. The feeling of working on code that is used\nby millions of developers and companies around the world is very rewarding.\n\nI plan to remain involved with the Git community even after GSoC by continuing\nto contribute patches, review code, and participate in discussions to help make\nGit better for end users. The work on refactoring Git’s global state is part of\na long-term effort, and I would love to continue working on it beyond the GSoC\ntimeline.\n\nI would also be happy to mentor, co-mentor, or volunteer in the future to help\nnew and upcoming contributors whenever I get the chance. I see GSoC as the\nstarting point of a long-term relationship with the Git community.\n\nClosing & Appreciation:\n-----------------------\n\nI would like to thank the Git community for the excellent documentation and the\nwelcoming environment. I am also grateful for the patience and guidance shown\nin the feedback and discussions on the mailing list by Junio, Phillip, Karthik,\nBen, and others, which have helped me improve my understanding and contributions.\n\nI also read blogs and proposals by Ayush, Lucas, Kousik Sanagavarapu, and Olamide\nBello, which provided valuable insights and helped shape my approach to contributing.\n\nThank you for reviewing my proposal :)\n\nReferences:\n-----------\n\n[1]- https://lore.kernel.org/git/cover.1771511192.git.phillip.wood@dunelm.org.uk/\n\n[2]- https://lore.kernel.org/git/20260304145823.189440-1-shreyanshpaliwalcmsmn@gmail.com/T/#m65b9b4547036991a7b7f3c861b9663428891f588\n\n[3]- https://lore.kernel.org/git/20260114143238.536312-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[4]- https://lore.kernel.org/git/20260115211609.17420-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[5]- https://lore.kernel.org/git/20260204111343.71975-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[6]- https://lore.kernel.org/git/20260205131132.44282-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[7]- https://lore.kernel.org/git/1444778207-859-1-git-send-email-gitster@pobox.com/\n\n[8]- https://lore.kernel.org/git/20160511131745.2914-1-chriscool@tuxfamily.org/\n\n[9]- https://lore.kernel.org/git/20180205235508.216277-1-sbeller@google.com/\n\n[10]- https://lore.kernel.org/git/20170531214417.38857-1-bmwill@google.com/\n\n[11]- https://lore.kernel.org/git/cover.1715339393.git.ps@pks.im/\n\n[12]- https://lore.kernel.org/git/20250206-b4-pks-path-drop-the-repository-v1-16-4e77f0313206@pks.im/\n\n[13]- https://lore.kernel.org/git/20250717-pks-config-wo-the-repository-v1-20-d888e4a17de1@pks.im/\n\n[14]- https://lore.kernel.org/git/cover.1718347699.git.ps@pks.im/\n\n[15]- https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html\n\n[16]- https://cloobtech.hashnode.dev/week-5-and-6-design-reviews-rfcs-and-refining-the-path-forward\n\n[17]- https://lore.kernel.org/all/cover.1771258573.git.belkid98@gmail.com/\n\n[18]- https://lore.kernel.org/git/7b5dd0c4-0ca0-458e-89db-621a70dac9ae@gmail.com/\n\n[19]- https://lore.kernel.org/git/20260217163909.55094-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[20]- https://medium.com/@shreyanshpaliwal18\n"},{"id":"538173","messageId":"CAP8UFD2cchYrwbhym1m9Kif7hBu3BXaK2YvOexwZT+Lcfi30LQ@mail.gmail.com","threadId":"65152","inReplyTo":"20260306151605.29330-1-shreyanshpaliwalcmsmn@gmail.com","subject":"Re: [GSOC][PROPOSAL]: Refactoring in order to reduce Git’s global state","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-07T10:33:02Z","receivedAt":"2026-03-07T10:33:14Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Shreyansh,\n\nOn Fri, Mar 6, 2026 at 4:16 PM Shreyansh Paliwal\n wrote:\n>\n> Hello all,\n>\n> This is my first draft of GSoC 2026 proposal for the project\n> 'Refactoring in order to reduce Git’s global state'.\n\nThanks for your interest in Git.\n\n> I am Shreyansh Paliwal, a pre-final year undergraduate student at Guru\n> Gobind Singh Indraprastha University, New Delhi, India. I am a technology\n> enthusiast, who began programming in 2018 with Java as my first language\n> and later transitioned to C/C++ in 2023 as my primary focus. I enjoy\n> exploring new technologies and programming languages, and I have developed\n> solid experience building applications using TypeScript, React.js, Node.js,\n> and AWS. I actively participate in technical events and have organized\n> multiple hackathons, tech-fests, and related activities at my college as\n> the SIG-Head of IOSD, a tech-focused student community.\n\nInteresting. Do you have links about these?\n\n> Pre-GSOC:\n> ---------\n\n> During this process, I attempted to remove the usage of the_repository from\n> a file. However, after discussion on the mailing list, Phillip pointed out\n> that the change was not particularly useful in that context and could\n> introduce segfaults that would not justify the effort for builtin code.\n> Based on this feedback, I dropped that attempt and instead focused on\n> understanding the broader global state refactoring effort. To better\n> understand the project area, I studied previous patches and blog posts by\n> Ayush Chandekar and Olamide Bello, followed discussions on the mailing\n> list, and explored parts of the codebase such as the wt-status and worktree\n> subsystems. This helped me understand the ongoing effort to reduce Git’s\n> reliance on global state and motivated me to work further in this area.\n>\n> The following is a list of my contributions, ordered from earliest to most\n> recent:\n>\n> Patches for Git:\n> ----------------\n>\n> * test-lib-functions.sh: fix test_grep fail message wording\n> Status: Merged into master\n\nThe status should be \"Released as part of v2.43.1\" or something like\nthat as far as I can see.\n\n> Mailing List: https://lore.kernel.org/git/20231203171956.771-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: 37e8d795bed7b93d3f12bcdd3fbb86dfe57921e6\n\nIf you say \"Merge Commit\" we expect the commit that merged your work.\nIt looks like this commit contains your work, so I think it's better\nto just say \"Commit\" instead.\n\n> Log: This was my first patch to Git in 2023. While browsing the\n> source code and past issues, I noticed that even after\n> the test_i18ngrep function was deprecated, an error message\n> referring to test_grep was left behind. I updated the\n> wording to correctly reference test_i18ngrep.\n\nI think it should be something like:\n\n... even after the test_i18ngrep function was deprecated, an error\nmessage referring to test_i18ngrep was left behind. I updated the\nwording to correctly reference test_grep.\n\n> * doc: MyFirstContribution: fix missing dependencies and clarify build steps\n> Status: Merged into master\n> Mailing List: https://lore.kernel.org/git/20260112195625.391821-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: 81021871eaa8b16a892b9c8791a0c905ab26e342\n\nSame thing about \"Merge Commit\" vs \"Commit\". Below too.\n\n> Log: While getting familiar with the codebase, I followed the\n> MyFirstContribution documentation and encountered a few\n> issues. Some include headers were missing, the synopsis\n> format was incorrect, and the explanation for -j$(nproc)\n> was absent. I submitted fixes to improve the clarity and\n> correctness of the documentation.\n>\n> * t5500: simplify test implementation and fix git exit code suppression (Microproject)\n> Status: Merged into master\n> Mailing List: https://lore.kernel.org/git/20260121130012.888299-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: a824421d3644f39bfa8dfc75876db8ed1c7bcdbf\n> Log: This was completed as a microproject for GSoC. Instead of\n> constructing the pack protocol using a complex combination\n> of here-docs and echo commands, the patch captures command\n> outputs beforehand and uses the test-tool pkt-line pack\n> helper to construct the protocol input in a temporary file\n> before feeding it to git upload-pack.\n>\n> * show-index: add warning and wrap error messages with gettext\n> Status: Merged into master\n> Mailing List: https://lore.kernel.org/git/20260130153603.290196-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: ea39808a22714b8f61b9472de7ef467ced15efea,\n> 227e2cc4e1415c4aeadceef527dd33e478ad5ec3\n> Log: While exploring the code, I noticed a TODO comment suggesting\n> automatic hash detection. After discussion on the mailing\n> list, it was concluded that there was no future-proof\n> approach to implement this until a new index file format\n> came into use. Instead, an explicit warning was added rather\n> than silently falling back to SHA-1. Additionally, several\n> error messages were missing gettext wrapping, which was also\n> fixed.\n>\n> * wt-status: reduce reliance on global state\n> Status: Merged into seen\n\nWhen a patch series isn't yet merged into next, it's better to tell\nwhat's its status in Junio's latest \"What's cooking in git.git ...\"\nemail. For this one, it looks like it is \"Will merge to 'next'.\".\n\n> Mailing List: https://lore.kernel.org/git/20260218175654.66004-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: a7cd24de0b3b679c16ae3ee8215af06aeea1e6a3,\n> 9d0d2ba217f3ceefb0315b556f012edb598b9724,\n> 4631e22f925fa2af8d8548af97ee2215be101409\n> Log: This has been the most significant patch series in my journey\n> so far. It began with a suggestion from Phillip to clean up\n> some the_repository usages in wt-status.c. I extended the\n> effort to remove all usages of the_repository and\n> the_hash_algo from the file. During review discussions, it\n> was suggested that some worktree API cleanup should happen\n> first, particularly regarding the representation of worktrees\n> as NULL. Some related changes were later moved to a separate\n> series, after which this refactoring proceeded.\n>\n> * worktree: change representation and usage of primary worktree\n> Status: Continued by Phillip Wood [1]\n\nHere you can also say that they have been merged into master. Maybe:\n\"Status: Merged into master after being continued by Phillip Wood\"\n\n> Mailing List: https://lore.kernel.org/git/20260213120529.15475-1-shreyanshpaliwalcmsmn@gmail.com/\n> Log: This worktree API cleanup series started while I was working\n> on wt-status. The intention was to modify the representation\n> of the current worktree so that struct worktree would not be\n> NULL. During discussion, Phillip clarified that NULL actually\n> represents the current worktree rather than the primary\n> worktree. Since Phillip already had a patch based on the right\n> logic, he continued the series and it was eventually merged\n> into master.\n>\n> * tree-diff: remove the usage of the_hash_algo global\n> Status: Merged into master\n> Mailing List: https://lore.kernel.org/git/20260220175331.1250726-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: 1e50d839f8592daf364778298a61670c4b998654\n> Log: This was a straightforward patch that removed the remaining\n> usages of the global the_hash_algo in tree-diff.c by using the\n> repository’s local instance instead.\n>\n> * send-email: UTF-8 encoding in subject line\n> Status: Merged into seen\n> Mailing List: https://lore.kernel.org/git/20260228112210.270273-1-shreyanshpaliwalcmsmn@gmail.com/\n> Merge Commit: c52f085a477c8eece87821c5bbc035e5a900eb12\n> Log: This patch was motivated by an issue I personally encountered\n> while sending a GSoC discussion email [2]. Initially the\n> change only modified the wording of the prompt, but after\n> discussion on the mailing list it was extended to include\n> proper validation to prevent invalid charset encodings from\n> being used in git send-email and to reduce confusion.\n>\n> * Remove global state from editor.c\n> Status: Waiting for further feedback\n> Mailing List: https://lore.kernel.org/git/20260301105228.1738388-1-shreyanshpaliwalcmsmn@gmail.com/\n> Log: This was based on my doubt on localizing editor_program in\n> editor.c [2]. The patch received mixed feedback from\n> contributors and is currently awaiting additional guidance\n> from mentor and/or maintainer regarding the appropriate\n> direction.\n>\n> Patches for git.github.io:\n> --------------------------\n>\n> * SoC-2026-ideas: Remove an extra backtick\n> Status: merged into master\n> PR Link: https://github.com/git/git.github.io/pull/831\n> Merge Commit: c1e4aa87a54430953eaa7355061139fdf1ff6796\n> Log: Minor Typo fix.\n>\n> * rn-132: fixed 2 typos\n> Status: merged into master\n> PR Link: https://github.com/git/git.github.io/pull/832\n> Merge Commit: 92876114d855d472ce2e0e5337e72a4b97b81681\n> Log: Fixed typos in Git Rev News Edition 132.\n>\n> I have also been involved in additional discussions on the Git mailing\n> list [3][4][5][6].\n\n[...]\n\n> Project Timeline:\n> ----------------\n>\n> * Community Bonding (Until May 24):\n> - Discuss the project direction and design approaches with mentors.\n> - Identify and prioritize two main areas of work:\n> + files that rely on the_repository.\n> + global variables defined in environment.c.\n> - Study the previous patches by Olamide Bello and Ayush in depth and\n> also discuss with them about their approaches and challenges.\n> - Interact with all the people involved in this work to better\n> understand design decisions and potential pitfalls.\n> - Experiment with small RFC patches, if needed to validate approaches.\n>\n> * Coding period (May 25 - August 16):\n> - Review the work done by Olamide Bello on moving values parsed by\n> git_default_config() into the repo_config_values structure and\n> identify any remaining tasks.\n\nI think this should be part of the Community Bonding period.\n\n> - Complete remaining cleanup or refactoring related to the worktree API,\n> if left any [19].\n> - Identify straightforward refactors to remove usages of the_repository\n> in files such as xdiff-interface.c, archive*.c, fsmonitor*.c etc.\n> - Work file by file with the goal of eliminating\n> #define USE_THE_REPOSITORY_VARIABLE by replacing global usages\n> with explicit repository instances.\n> - Concurrently maintain at least two parallel patch series:\n> + Small / straightforward refactors and replacements like\n> the_hash_algo or the_repostitory.\n> + Larger structural refactors involving globals such as\n> DEFAULT_ABBREV, comment_line_str etc.\n> - Publish weekly or biweekly blog updates documenting progress and design\n> decisions.\n>\n> * Final week (august 17 - august 24):\n> - Address any remaining tasks or pending patches.\n> - Recieve final feedback from mentors and reviewers.\n\ns/Recieve/Receive/\n\n> - Prepare a detailed report summarizing the work completed during the project.\n\n\nThanks for your proposal!\n"},{"id":"538176","messageId":"20260307125740.95052-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65152","inReplyTo":"CAP8UFD2cchYrwbhym1m9Kif7hBu3BXaK2YvOexwZT+Lcfi30LQ@mail.gmail.com","subject":"Re: [GSOC][PROPOSAL]: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-03-07T12:46:49Z","receivedAt":"2026-03-07T12:58:16Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"> Hi Shreyansh,\n>\n> On Fri, Mar 6, 2026 at 4:16 PM Shreyansh Paliwal\n> wrote:\n> >\n> > Hello all,\n> >\n> > This is my first draft of GSoC 2026 proposal for the project\n> > 'Refactoring in order to reduce Git’s global state'.\n>\n> Thanks for your interest in Git.\n>\n> > I am Shreyansh Paliwal, a pre-final year undergraduate student at Guru\n> > Gobind Singh Indraprastha University, New Delhi, India. I am a technology\n> > enthusiast, who began programming in 2018 with Java as my first language\n> > and later transitioned to C/C++ in 2023 as my primary focus. I enjoy\n> > exploring new technologies and programming languages, and I have developed\n> > solid experience building applications using TypeScript, React.js, Node.js,\n> > and AWS. I actively participate in technical events and have organized\n> > multiple hackathons, tech-fests, and related activities at my college as\n> > the SIG-Head of IOSD, a tech-focused student community.\n>\n> Interesting. Do you have links about these?\n\nYup, I can gather some related links for these, will add them.\n\n>\n> > Pre-GSOC:\n> > ---------\n>\n> > During this process, I attempted to remove the usage of the_repository from\n> > a file. However, after discussion on the mailing list, Phillip pointed out\n> > that the change was not particularly useful in that context and could\n> > introduce segfaults that would not justify the effort for builtin code.\n> > Based on this feedback, I dropped that attempt and instead focused on\n> > understanding the broader global state refactoring effort. To better\n> > understand the project area, I studied previous patches and blog posts by\n> > Ayush Chandekar and Olamide Bello, followed discussions on the mailing\n> > list, and explored parts of the codebase such as the wt-status and worktree\n> > subsystems. This helped me understand the ongoing effort to reduce Git’s\n> > reliance on global state and motivated me to work further in this area.\n> >\n> > The following is a list of my contributions, ordered from earliest to most\n> > recent:\n> >\n> > Patches for Git:\n> > ----------------\n> >\n> > * test-lib-functions.sh: fix test_grep fail message wording\n> > Status: Merged into master\n>\n> The status should be \"Released as part of v2.43.1\" or something like\n> that as far as I can see.\n\nRight, got it.\n\n> > Mailing List: https://lore.kernel.org/git/20231203171956.771-1-shreyanshpaliwalcmsmn@gmail.com/\n> > Merge Commit: 37e8d795bed7b93d3f12bcdd3fbb86dfe57921e6\n>\n> If you say \"Merge Commit\" we expect the commit that merged your work.\n> It looks like this commit contains your work, so I think it's better\n> to just say \"Commit\" instead.\n>\n\nUnderstood. I will change \"Merge Commit\" to \"Commit\" for all the patches.\n\n> > Log: This was my first patch to Git in 2023. While browsing the\n> > source code and past issues, I noticed that even after\n> > the test_i18ngrep function was deprecated, an error message\n> > referring to test_grep was left behind. I updated the\n> > wording to correctly reference test_i18ngrep.\n>\n> I think it should be something like:\n>\n> ... even after the test_i18ngrep function was deprecated, an error\n> message referring to test_i18ngrep was left behind. I updated the\n> wording to correctly reference test_grep.\n>\n\nOops, I'll fix the wording.\n\n> > * doc: MyFirstContribution: fix missing dependencies and clarify build steps\n> > Status: Merged into master\n> > Mailing List: https://lore.kernel.org/git/20260112195625.391821-1-shreyanshpaliwalcmsmn@gmail.com/\n> > Merge Commit: 81021871eaa8b16a892b9c8791a0c905ab26e342\n>\n> Same thing about \"Merge Commit\" vs \"Commit\". Below too.\n>\n> > Log: While getting familiar with the codebase, I followed the\n> > MyFirstContribution documentation and encountered a few\n> > issues. Some include headers were missing, the synopsis\n> > format was incorrect, and the explanation for -j$(nproc)\n> > was absent. I submitted fixes to improve the clarity and\n> > correctness of the documentation.\n> >\n> > * t5500: simplify test implementation and fix git exit code suppression (Microproject)\n> > Status: Merged into master\n> > Mailing List: https://lore.kernel.org/git/20260121130012.888299-1-shreyanshpaliwalcmsmn@gmail.com/\n> > Merge Commit: a824421d3644f39bfa8dfc75876db8ed1c7bcdbf\n> > Log: This was completed as a microproject for GSoC. Instead of\n> > constructing the pack protocol using a complex combination\n> > of here-docs and echo commands, the patch captures command\n> > outputs beforehand and uses the test-tool pkt-line pack\n> > helper to construct the protocol input in a temporary file\n> > before feeding it to git upload-pack.\n> >\n> > * show-index: add warning and wrap error messages with gettext\n> > Status: Merged into master\n> > Mailing List: https://lore.kernel.org/git/20260130153603.290196-1-shreyanshpaliwalcmsmn@gmail.com/\n> > Merge Commit: ea39808a22714b8f61b9472de7ef467ced15efea,\n> > 227e2cc4e1415c4aeadceef527dd33e478ad5ec3\n> > Log: While exploring the code, I noticed a TODO comment suggesting\n> > automatic hash detection. After discussion on the mailing\n> > list, it was concluded that there was no future-proof\n> > approach to implement this until a new index file format\n> > came into use. Instead, an explicit warning was added rather\n> > than silently falling back to SHA-1. Additionally, several\n> > error messages were missing gettext wrapping, which was also\n> > fixed.\n> >\n> > * wt-status: reduce reliance on global state\n> > Status: Merged into seen\n>\n> When a patch series isn't yet merged into next, it's better to tell\n> what's its status in Junio's latest \"What's cooking in git.git ...\"\n> email. For this one, it looks like it is \"Will merge to 'next'.\".\n>\n\nYes, merging to next was just confirmed in the latest Mar 2026 #03,\nbefore this it was still with a question mark and pending for any comments.\nI will update the status, including for the send-email patch.\n\n> > Mailing List: https://lore.kernel.org/git/20260218175654.66004-1-shreyanshpaliwalcmsmn@gmail.com/\n> > Merge Commit: a7cd24de0b3b679c16ae3ee8215af06aeea1e6a3,\n> > 9d0d2ba217f3ceefb0315b556f012edb598b9724,\n> > 4631e22f925fa2af8d8548af97ee2215be101409\n> > Log: This has been the most significant patch series in my journey\n> > so far. It began with a suggestion from Phillip to clean up\n> > some the_repository usages in wt-status.c. I extended the\n> > effort to remove all usages of the_repository and\n> > the_hash_algo from the file. During review discussions, it\n> > was suggested that some worktree API cleanup should happen\n> > first, particularly regarding the representation of worktrees\n> > as NULL. Some related changes were later moved to a separate\n> > series, after which this refactoring proceeded.\n> >\n> > * worktree: change representation and usage of primary worktree\n> > Status: Continued by Phillip Wood [1]\n>\n> Here you can also say that they have been merged into master. Maybe:\n> \"Status: Merged into master after being continued by Phillip Wood\"\n>\n\nMakes sense. I'll update this.\n\n> > Mailing List: https://lore.kernel.org/git/20260213120529.15475-1-shreyanshpaliwalcmsmn@gmail.com/\n> > Log: This worktree API cleanup series started while I was working\n> > on wt-status. The intention was to modify the representation\n> > of the current worktree so that struct worktree would not be\n> > NULL. During discussion, Phillip clarified that NULL actually\n> > represents the current worktree rather than the primary\n> > worktree. Since Phillip already had a patch based on the right\n> > logic, he continued the series and it was eventually merged\n> > into master.\n\n[...]\n\n> >\n> > * Coding period (May 25 - August 16):\n> > - Review the work done by Olamide Bello on moving values parsed by\n> > git_default_config() into the repo_config_values structure and\n> > identify any remaining tasks.\n>\n> I think this should be part of the Community Bonding period.\n>\n> > - Complete remaining cleanup or refactoring related to the worktree API,\n> > if left any [19].\n> > - Identify straightforward refactors to remove usages of the_repository\n> > in files such as xdiff-interface.c, archive*.c, fsmonitor*.c etc.\n> > - Work file by file with the goal of eliminating\n> > #define USE_THE_REPOSITORY_VARIABLE by replacing global usages\n> > with explicit repository instances.\n> > - Concurrently maintain at least two parallel patch series:\n> > + Small / straightforward refactors and replacements like\n> > the_hash_algo or the_repostitory.\n> > + Larger structural refactors involving globals such as\n> > DEFAULT_ABBREV, comment_line_str etc.\n> > - Publish weekly or biweekly blog updates documenting progress and design\n> > decisions.\n> >\n> > * Final week (august 17 - august 24):\n> > - Address any remaining tasks or pending patches.\n> > - Recieve final feedback from mentors and reviewers.\n>\n> s/Recieve/Receive/\n>\n> > - Prepare a detailed report summarizing the work completed during the project.\n>\n>\n> Thanks for your proposal!\n\nThanks Christian, for reading and for the suggestions, I'll revise\nand send an updated version on this.\n"},{"id":"538179","messageId":"20260307200926.149273-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65152","inReplyTo":"20260306151605.29330-1-shreyanshpaliwalcmsmn@gmail.com","subject":"[GSOC][PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-03-07T20:04:00Z","receivedAt":"2026-03-07T20:09:41Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"Hello,\n\nThis is my second draft of GSoC 2026 proposal for the project\n'Refactoring in order to reduce Git’s global state'.\n\nDoc version can be read at:\nhttps://docs.google.com/document/d/16MRNUv6dJi6vtNvI5Ro0WmHf20dRRBHjFLpmhAuaUOA/edit?usp=sharing\n\nAny feedback or suggestions would be greatly appreciated.\n\nThanks for reading.\n---\n\nChanges in v2:\n - Added links in the 'About Me' section and updated reference numbering.\n - Rephrased and revised the 'Pre-GSoC', 'History' and 'Proposed Plan' sections.\n - Updated patch statuses and changed some wordings.\n---\n\nRefactoring in order to reduce Git's global state\n\nPersonal Information:\n---------------------\n\nName: Shreyansh Paliwal\nEmail: Shreyanshpaliwalcmsmn@gmail.com\nAlternate Email: Shreyansh.01014803123@it.mait.ac.in\nMobile No.: +91-9335120023\n\nEducation: GGSIPU, New Delhi, India\nYear: III / IV\nDegree: Bachelor of Technology in Information Technology\n\nGithub: https://github.com/shreyp135\nTime-zone: UTC +5:30 (IST)\n\nAbout Me:\n---------\n\nI am Shreyansh Paliwal, a pre-final year undergraduate student at Guru\nGobind Singh Indraprastha University, New Delhi, India. I am a technology\nenthusiast, who began programming in 2018 with Java as my first language\nand later transitioned to C/C++ in 2023 as my primary focus. I enjoy\nexploring new technologies and programming languages, and have developed\nsolid experience building applications such as [1] using TypeScript,\nReact.js, Node.js, and AWS. I actively participate in technical events and\nhave organized multiple hackathons [2], tech-fests [3], and related\nactivities at my college as the SIG-Head of IOSD [4], a tech-focused\nstudent community.\n\nI started using Git in 2023, which is also when I made my first open-source\ncontribution to the Git project. I was a winner of Augtoberfest 2024 [5],\nan open-source competition organized by C4GT India. Over the past several\nmonths, I have been involved with the Git project, studying the codebase,\nsubmitting patches, and incorporating review feedback. I am motivated to\nimprove the experience of Git for end users, and this project is an\nexcellent opportunity to continue that work.\n\nOverview:\n---------\n\nGit relies heavily on global state for managing environment variables and\nconfiguration data. In particular, many parts of the codebase depend on the\nglobal struct repository instance, the_repository, which represents the\ncurrently active repository. Instead of passing a repository instance\nexplicitly, several internal functions implicitly rely on this global\nobject. Additionally, various configuration derived values and\nenvironment-related variables such as the_hash_algo, default_abbrev, and\ncomment_line_str are stored globally, most of them defined in\nenvironment.c.\n\nThis design assumes that only one repository is active within a process at\na time. As a result, the repository state becomes shared across the entire\nprocess, weakening isolation and making behavior implicitly dependent on\nglobal context. Such global dependencies make the code harder to reason\nabout, test, and maintain, and can introduce subtle bugs when operations\ninteract with multiple repositories. They also limit long-term goals such\nas safely supporting multiple repositories within a single process and\ncontinuing Git’s ongoing libification efforts.\n\nTo address these issues, global environment and configuration state should\nbe refactored into better-scoped contexts. Repository-specific data can be\nmoved into struct repository or related structures, while\nsubsystem-specific state should be localized appropriately. Passing\nrepository instances explicitly through function interfaces will improve\nmodularity, reduce hidden dependencies, and make the codebase easier to\nmaintain while moving Git closer to supporting multiple repositories safely\nwithin a single process.\n\nThe difficulty of this project is medium, and it is estimated to take 175\nto 350 hours.\n\nPre-GSOC:\n---------\n\nI first explored the Git codebase in December 2023, when I submitted a\nsmall patch fixing the wording of an error message that I noticed while\nbrowsing the source code. At that time I had recently started using Git and\nGitHub for version control in my projects, which sparked my curiosity about\nhow Git works internally. A few months ago, when I had some free time\nfrom college, I decided to start contributing to Git more actively. I built\nGit from source, read parts of the documentation, and familiarized myself\nwith the mailing list workflow. While going through the documentation, I\nnoticed a few inconsistencies in the MyFirstContribution page and submitted\npatches to fix them. I also completed a microproject involving a test\ncleanup, and later worked on adding a warning for a quiet fallback.\n\nDuring this process, I attempted to remove the usage of the_repository from\na file. After discussion on the mailing list [23], Phillip directed me\ntowards wt-status, which led me to explore parts of the codebase such as\nthe wt-status and worktree subsystems. Through this, I learned that such\nrefactors are generally more valuable in core library code. Following this\ndiscussion, I shifted my focus toward understanding the broader global\nstate refactoring effort. To better understand the project area, I studied\nprevious patches and blog posts by Ayush Chandekar and Olamide Bello,\nfollowed related discussions on the mailing list, and explored the relevant\nparts of the codebase. This motivated me to work further in this area and\nshaped my interest in this project.\n\nThe following is a list of my contributions, ordered from earliest to most\nrecent:\n\nPatches for Git:\n----------------\n\n* test-lib-functions.sh: fix test_grep fail message wording\n Status: Released in v2.43.1\n Mailing List: https://lore.kernel.org/git/20231203171956.771-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 37e8d795bed7b93d3f12bcdd3fbb86dfe57921e6\n Log: This was my first patch to Git in 2023. While browsing the\n source code and past issues, I noticed that even after\n the test_i18ngrep function was deprecated, an error message\n referring to test_i18ngrep was left behind. I updated\n the wording to correctly reference test_grep.\n\n* doc: MyFirstContribution: fix missing dependencies and clarify build steps\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260112195625.391821-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 81021871eaa8b16a892b9c8791a0c905ab26e342\n Log: While getting familiar with the codebase, I followed the\n MyFirstContribution documentation and encountered a few\n issues. Some include headers were missing, the synopsis\n format was incorrect, and the explanation for -j$(nproc)\n was absent. I submitted fixes to improve the clarity and\n correctness of the documentation.\n\n* t5500: simplify test implementation and fix git exit code suppression (Microproject)\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260121130012.888299-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: a824421d3644f39bfa8dfc75876db8ed1c7bcdbf\n Log: This was completed as a microproject for GSoC. Instead of\n constructing the pack protocol using a complex combination\n of here-docs and echo commands, the patch captures command\n outputs beforehand and uses the test-tool pkt-line pack\n helper to construct the protocol input in a temporary file\n before feeding it to git upload-pack.\n\n* show-index: add warning and wrap error messages with gettext\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260130153603.290196-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: ea39808a22714b8f61b9472de7ef467ced15efea,\n 227e2cc4e1415c4aeadceef527dd33e478ad5ec3\n Log: While exploring the code, I noticed a TODO comment suggesting\n automatic hash detection. After discussion on the mailing\n list, it was concluded that there was no future-proof\n approach to implement this until a new index file format\n came into use. Instead, an explicit warning was added rather\n than silently falling back to SHA-1. Additionally, several\n error messages were missing gettext wrapping, which was also\n fixed.\n\n* wt-status: reduce reliance on global state\n Status: Will merge to next\n Mailing List: https://lore.kernel.org/git/20260218175654.66004-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: a7cd24de0b3b679c16ae3ee8215af06aeea1e6a3,\n 9d0d2ba217f3ceefb0315b556f012edb598b9724,\n 4631e22f925fa2af8d8548af97ee2215be101409\n Log: This has been the most significant patch series in my journey\n so far. It began with a suggestion from Phillip to clean up\n some the_repository usages in wt-status.c. I extended the\n effort to remove all usages of the_repository and\n the_hash_algo from the file. During review discussions, it\n was suggested that some worktree API cleanup should happen\n first, particularly regarding the representation of worktrees\n as NULL. Some related changes were later moved to a separate\n series, after which this refactoring proceeded.\n\n* worktree: change representation and usage of primary worktree\n Status: Merged into master after being continued by Phillip Wood [6]\n Mailing List: https://lore.kernel.org/git/20260213120529.15475-1-shreyanshpaliwalcmsmn@gmail.com/\n Log: This worktree API cleanup series started while I was working\n on wt-status. The intention was to modify the representation\n of the current worktree so that struct worktree would not be\n NULL. During discussion, Phillip clarified that NULL actually\n represents the current worktree rather than the primary\n worktree. Since Phillip already had a patch based on the right\n logic, he continued the series and it was eventually merged\n into master.\n\n* tree-diff: remove the usage of the_hash_algo global\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260220175331.1250726-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 1e50d839f8592daf364778298a61670c4b998654\n Log: This was a straightforward patch that removed the remaining\n usages of the global the_hash_algo in tree-diff.c by using the\n repository’s local instance instead.\n\n* send-email: UTF-8 encoding in subject line\n Status: Will merge to master\n Mailing List: https://lore.kernel.org/git/20260228112210.270273-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: c52f085a477c8eece87821c5bbc035e5a900eb12\n Log: This patch was motivated by an issue I personally encountered\n while sending a GSoC discussion email [7]. Initially the\n change only modified the wording of the prompt, but after\n discussion on the mailing list it was extended to include\n proper validation to prevent invalid charset encodings from\n being used in git send-email and to reduce confusion.\n\n* Remove global state from editor.c\n Status: Waiting for further feedback\n Mailing List: https://lore.kernel.org/git/20260301105228.1738388-1-shreyanshpaliwalcmsmn@gmail.com/\n Log: This originated from a question I had about localizing\n editor_program in editor.c [7]. The patch received some\n mixed feedback on whether editor_program state should\n instead become repository-scoped, since it can also be set\n via git config --local. I am currently awaiting further\n guidance from mentors on the appropriate direction.\n\nPatches for git.github.io:\n--------------------------\n\n* SoC-2026-ideas: Remove an extra backtick\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/831\n Merge Commit: c1e4aa87a54430953eaa7355061139fdf1ff6796\n Log: Minor Typo fix.\n\n* rn-132: fixed 2 typos\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/832\n Merge Commit: 92876114d855d472ce2e0e5337e72a4b97b81681\n Log: Fixed typos in Git Rev News Edition 132.\n\nI have also been involved in additional discussions on the Git mailing\nlist [8][9][10][11].\n\nHistory / Background:\n--------------------\n\nEfforts to reduce Git’s reliance on global state began as several\nsubsystems moved toward libification, enabling Git’s internal functionality\nto be reused as a library. Early examples include the libification of git\nmailinfo by Junio [12] and git apply by Christian [13], these large patch\nseries exposed the limitations of relying on global state and highlighted\nthe need for better encapsulation of repository-related data. A key step\nwas the introduction of struct repository through refactoring by Stefan\nBeller [14] and Brandon Williams [15], which was motivated to centralize\nrepository-related state instead of relying on scattered global variables,\nimproving code clarity while laying groundwork for future improvements such\nas safer multithreading and handling submodules in the same process. Later\nwork by Patrick further reduced reliance on the global the_repository in\nthe config [16] and path [17] subsystems, consolidating several variables\ninto environment.c so environment-related state could be managed in one\nplace [18]. The macro #define USE_THE_REPOSITORY_VARIABLE was also\nintroduced to help transition code away from implicit global repository\naccess [19].\n\nDuring GSoC 2025, Ayush Chandekar [20] removed additional usages of\nthe_repository across the codebase and moved several global configuration\nvariables (such as core_preload_index and merge_log_config) into\nrepository-scoped structures. More recently, during Outreachy, Olamide\nBello improved configuration handling by introducing repo_config_values, a\nstructure linked to struct repository that stores repository-specific\nconfiguration values [21][22]. A supporting private structure,\nconfig_values_private, was added for initialization and internal handling.\nDiscussions around this work also highlighted an important design\nconstraint: directly moving globals into repository structures or\nintroducing lazy loading helpers can cause user experience regressions if\nconfiguration errors are detected later.\n\nThese efforts collectively form the foundation of the ongoing work to\ngradually remove Git’s reliance on global state and move toward a more\nmodular, repository-scoped architecture.\n\nProposed Plan:\n-------------\n\nI started exploring the codebase by browsing relevant files and identifying\nglobal variables by temporarily removing the USE_THE_REPOSITORY_VARIABLE\nmacro. My primary focus was on core library files rather than builtin code\n[23]. Through this exploration, I observed that a large number of files still\ndepend on the_repository.\n\nTo tackle this project systematically, I propose classifying these files into\ntwo categories:\n\n1. Files using the_repository or the_hash_algo where a repository\n instance already exists: These files rely on global variables even\n though a struct repository instance is available somewhere in the\n call stack. A simple example is my patch in tree-diff.c, where a\n repository instance was already available through struct diff_options\n *opt, but the_hash_algo was still used. I replaced it with\n opt->repo->hash_algo.\n\n In such cases, the refactor mainly involves passing the repository\n instance through the function call stack and replacing the global\n usages. If a repository instance is not directly available in the\n file, I will trace the callers and propagate it from higher levels in\n the call hierarchy.\n Examples of such files include alias.c, archive*.c, walker.c, and\n xdiff-interface.c. These typically require localized refactoring and\n are good candidates for incremental patches.\n\n2. Files relying on other global variables defined in environment.c:\n Some files depend on additional global variables that are parsed and\n accessed through environment.c. In these cases, there is no existing\n repository-scoped instance, making the refactor slightly more involved.\n\n Examples include wt-status.c (default_abbrev, comment_line_str) and\n apply.c (has_symlink, ignore_case, trust_executable_bit,\n apply_default_whitespace, apply_default_ignorewhitespace).\n For such variables, I will evaluate whether they should be moved into\n repository-scoped structures (e.g., repo_settings or\n repo_config_values), or instead be localized and passed explicitly\n where needed. The appropriate approach will depend on how widely the\n variable is used and whether it logically belongs in a\n multi-repository standpoint.\n\nI plan to begin with the first category, addressing straightforward\nrefactors file by file. In parallel, I will analyze and work on specific\ngroups of global variables from the second category, designing\nappropriate repository-scoped replacements while preserving the\noriginal parsing timing and availability of those variables.\n\nThe end goal is to remove reliance on global state and eventually eliminate\nthe USE_THE_REPOSITORY_VARIABLE macro from these files.\n\nProject Timeline:\n----------------\n\n* Community Bonding (Until May 24):\n - Discuss the project direction and design approaches with mentors.\n - Identify and prioritize two main areas of work:\n + files that rely on the_repository.\n + global variables defined in environment.c.\n - Study the previous patches by Olamide Bello and Ayush Chandekar\n in depth, and identify any remaining tasks while discussing\n their approaches and challenges with them.\n - Interact with all the people involved in this work to better\n understand design decisions and potential pitfalls.\n - Experiment with small RFC patches, if needed to validate approaches.\n\n* Coding period (May 25 - August 16):\n - Send patches for any remaining cleanup or refactoring related to\n git_default_config() and repo_config_values [22], as well as\n the worktree API [24], if any.\n - Identify straightforward refactors to remove usages of the_repository\n in files such as xdiff-interface.c, archive*.c, fsmonitor*.c etc.\n - Work file by file with the goal of eliminating\n #define USE_THE_REPOSITORY_VARIABLE by replacing global usages\n with explicit repository instances.\n - Concurrently maintain at least two parallel patch series:\n + Small / straightforward refactors and replacements like\n the_hash_algo or the_repostitory.\n + Larger structural refactors involving globals such as\n DEFAULT_ABBREV, comment_line_str etc.\n - Publish weekly or biweekly blog updates documenting progress and design\n decisions.\n\n* Final week (August 17 - August 24):\n - Address any remaining tasks or pending patches.\n - Receive final feedback from mentors and reviewers.\n - Prepare a detailed report summarizing the work completed during the project.\n\nBlogging:\n---------\n\nI believe blogging is an important part of any open-source project. It\nhelps others understand the ongoing work and also enables the contributor\nto develop a deeper understanding and keep a better track of their own\nprogress. I experienced this firsthand, early in my journey I was unsure\nabout various aspects, but reading the blogs of Ayush and Olamide Bello\ngave me valuable insight into the contributor perspective and their overall\nwork.\n\nWith the goal of helping future contributors in a similar way, I plan to\ndocument my journey and project progress through regular blog posts. I will\npublish updates on a weekly or biweekly basis, depending on the amount of\nmeaningful progress made. I have set up my blogging area on Medium, and my\nposts will be available at [25].\n\n\nAvailability:\n-------------\n\nThe main coding period runs from June to August. Most of June and July\ncoincide with my summer vacation, which allows me to dedicate significant\ntime to the project. My final exams are scheduled for May and will last\napproximately one week, but they will be completed before the coding period\nbegins and should not affect my availability.\n\nDuring June and July, I will be able to dedicate around 40 hours per week to\nthe project. In August, when my regular semester resumes, I expect to\ncontribute approximately 25–30 hours per week.\nI do not have any other exams, internships, or planned vacations during the\ncoding period. Apart from this project, I have no other major commitments\nfor the summer.\n\nI will keep the community regularly updated on my progress throughout the\nproject. My primary mode of communication will be email, and I will also be\navailable for calls or meetings if/when required. My preferred availability\nwindow is 13:00–19:00 UTC.\n\nPost GSoC:\n----------\n\nBeing part of the Git community and contributing to the codebase has been a\nvery valuable experience for me. The process of understanding Git’s internals,\nsubmitting patches, and receiving feedback on the mailing list has helped me\ngrow significantly as a developer. The feeling of working on code that is used\nby millions of developers and companies around the world is very rewarding.\n\nI plan to remain involved with the Git community even after GSoC by continuing\nto contribute patches, review code, and participate in discussions to help make\nGit better for end users. The work on refactoring Git’s global state is part of\na long-term effort, and I would love to continue working on it beyond the GSoC\ntimeline.\n\nI would also be happy to mentor, co-mentor, or volunteer in the future to help\nnew and upcoming contributors whenever I get the chance. I see GSoC as the\nstarting point of a long-term relationship with the Git community.\n\nClosing & Appreciation:\n-----------------------\n\nI would like to thank the Git community for the excellent documentation and the\nwelcoming environment. I am also grateful for the patience and guidance shown\nin the feedback and discussions on the mailing list by Junio, Phillip, Karthik,\nBen, and others, which have helped me improve my understanding and contributions.\n\nI also read blogs and proposals by Ayush, Lucas, Kousik Sanagavarapu, and Olamide\nBello, which provided valuable insights and helped shape my approach to contributing.\n\nThank you for reviewing my proposal :)\n\nReferences:\n-----------\n\n[1]- https://github.com/shreyp135/Alethea\n\n[2]- https://unstop.com/hackathons/hackmait-50-iosd-impulse-2024-maharaja-agrasen-institute-of-technology-mait-new-delhi-941779\n\n[3]- https://cse.mait.ac.in/index.php/academics/9-computer-center/1249-iosd-mait-impulse-25, https://unstop.com/college-fests/impulse-2025-maharaja-agrasen-institute-of-technology-mait-new-delhi-348321\n\n[4]- https://iosd-web.vercel.app/\n\n[5]- https://www.linkedin.com/posts/code-for-goodtech_augtoberfest-c4gt2024-activity-7242923677032312834-XMul\n\n[6]- https://lore.kernel.org/git/cover.1771511192.git.phillip.wood@dunelm.org.uk/\n\n[7]- https://lore.kernel.org/git/20260304145823.189440-1-shreyanshpaliwalcmsmn@gmail.com/T/#m65b9b4547036991a7b7f3c861b9663428891f588\n\n[8]- https://lore.kernel.org/git/20260114143238.536312-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[9]- https://lore.kernel.org/git/20260115211609.17420-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[10]- https://lore.kernel.org/git/20260204111343.71975-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[11]- https://lore.kernel.org/git/20260205131132.44282-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[12]- https://lore.kernel.org/git/1444778207-859-1-git-send-email-gitster@pobox.com/\n\n[13]- https://lore.kernel.org/git/20160511131745.2914-1-chriscool@tuxfamily.org/\n\n[14]- https://lore.kernel.org/git/20180205235508.216277-1-sbeller@google.com/\n\n[15]- https://lore.kernel.org/git/20170531214417.38857-1-bmwill@google.com/\n\n[16]- https://lore.kernel.org/git/cover.1715339393.git.ps@pks.im/\n\n[17]- https://lore.kernel.org/git/20250206-b4-pks-path-drop-the-repository-v1-16-4e77f0313206@pks.im/\n\n[18]- https://lore.kernel.org/git/20250717-pks-config-wo-the-repository-v1-20-d888e4a17de1@pks.im/\n\n[19]- https://lore.kernel.org/git/cover.1718347699.git.ps@pks.im/\n\n[20]- https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html\n\n[21]- https://cloobtech.hashnode.dev/week-5-and-6-design-reviews-rfcs-and-refining-the-path-forward\n\n[22]- https://lore.kernel.org/all/cover.1771258573.git.belkid98@gmail.com/\n\n[23]- https://lore.kernel.org/git/7b5dd0c4-0ca0-458e-89db-621a70dac9ae@gmail.com/\n\n[24]- https://lore.kernel.org/git/20260217163909.55094-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[25]- https://medium.com/@shreyanshpaliwal18\n"},{"id":"538278","messageId":"CAP8UFD3=FdwyX66gGaLg01VU+Euw=fV8s4gPPOXEXDFn+11yRg@mail.gmail.com","threadId":"65152","inReplyTo":"20260307200926.149273-1-shreyanshpaliwalcmsmn@gmail.com","subject":"Re: [GSOC][PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-03-09T14:42:26Z","receivedAt":"2026-03-09T14:42:39Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Shreyansh,\n\nOn Sat, Mar 7, 2026 at 9:09 PM Shreyansh Paliwal\n wrote:\n\n> Changes in v2:\n> - Added links in the 'About Me' section and updated reference numbering.\n> - Rephrased and revised the 'Pre-GSoC', 'History' and 'Proposed Plan' sections.\n> - Updated patch statuses and changed some wordings.\n\nThanks. Your proposal looks good to me now.\n"},{"id":"538457","messageId":"20260310150054.126372-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65152","inReplyTo":"CAP8UFD3=FdwyX66gGaLg01VU+Euw=fV8s4gPPOXEXDFn+11yRg@mail.gmail.com","subject":"Re: [GSOC][PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-03-10T14:58:24Z","receivedAt":"2026-03-10T15:01:25Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"> Hi Shreyansh,\n>\n> On Sat, Mar 7, 2026 at 9:09 PM Shreyansh Paliwal\n> wrote:\n>\n> > Changes in v2:\n> > - Added links in the 'About Me' section and updated reference numbering.\n> > - Rephrased and revised the 'Pre-GSoC', 'History' and 'Proposed Plan' sections.\n> > - Updated patch statuses and changed some wordings.\n>\n> Thanks. Your proposal looks good to me now.\n\nThanks Christian for taking the time to review it.\nIf there are any updates to the patch list or the proposal content,\nI will send a v3 in a few days, before the final submission.\n\nBest,\nShreyansh\n"},{"id":"539576","messageId":"20260320181655.1395831-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65152","inReplyTo":"20260307200926.149273-1-shreyanshpaliwalcmsmn@gmail.com","subject":"[GSOC][PROPOSAL v3]: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-03-20T18:12:42Z","receivedAt":"2026-03-20T18:17:38Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"Hello,\n\nThis is my third draft of GSoC 2026 proposal for the project\n'Refactoring in order to reduce Git’s global state'.\n\nDoc version can be read at:\nhttps://docs.google.com/document/d/16MRNUv6dJi6vtNvI5Ro0WmHf20dRRBHjFLpmhAuaUOA/edit?usp=sharing\n\nI have also uploaded this draft to the GSoC website. Any\nfinal feedback or suggestions would be greatly appreciated.\n\nThanks for reading.\n---\n\nChanges in v3:\n - Updated patch list and their statuses.\n - Minor wording and grammar changes.\n---\n\nRefactoring in order to reduce Git's global state\n\nPersonal Information:\n---------------------\n\nName: Shreyansh Paliwal\nEmail: Shreyanshpaliwalcmsmn@gmail.com\nAlternate Email: Shreyansh.01014803123@it.mait.ac.in\nMobile No.: +91-9335120023\n\nEducation: GGSIPU, New Delhi, India\nYear: III / IV\nDegree: Bachelor of Technology in Information Technology\n\nGithub: https://github.com/shreyp135\nTime-zone: UTC +5:30 (IST)\n\nAbout Me:\n---------\n\nI am Shreyansh Paliwal, a pre-final year undergraduate student at Guru\nGobind Singh Indraprastha University, New Delhi, India. I began programming\nin 2018 with Java as my first language and later transitioned to C/C++ in\n2023, and it has been my primary focus since then. I also enjoy exploring\nnew technologies and building applications such as [1], which I developed\nusing TypeScript, React.js, and AWS. I have also organized multiple\nhackathons and technical fests [2][3] at my college as the SIG-Head of\nIOSD [4], a tech-focused student community.\n\nI started using Git in 2023, which is also when I made my first open-source\ncontribution to the Git project. I was also a winner of Augtoberfest 2024\n[5], an open-source competition organized by C4GT India. Over the past\nseveral months, I have been actively contributing to Git by studying the\ncodebase, becoming familiar with the mailing list workflow, and submitting\nmultiple patches after incorporating review feedback. I am motivated to\nimprove the experience of Git for end users, and this project is an\nexcellent opportunity to continue that work.\n\nOverview:\n---------\n\nGit relies heavily on global state for managing environment variables and\nconfiguration data. In particular, many parts of the codebase depend on the\nglobal struct repository instance, the_repository, which represents the\ncurrently active repository. Instead of passing a repository instance\nexplicitly, several internal functions implicitly rely on this global\nobject. Additionally, various configuration derived values and\nenvironment-related variables such as the_hash_algo, default_abbrev, and\ncomment_line_str are stored globally, most of them defined in\nenvironment.c.\n\nThis design assumes that only one repository is active within a process at\na time. As a result, the repository state becomes shared across the entire\nprocess, weakening isolation and making behavior implicitly dependent on\nglobal context. Such global dependencies make the code harder to reason\nabout, test, and maintain, and can introduce subtle bugs when operations\ninteract with multiple repositories. They also limit long-term goals such\nas safely supporting multiple repositories within a single process and\ncontinuing Git’s ongoing libification efforts.\n\nTo address these issues, global environment and configuration state should\nbe refactored into better-scoped contexts. Repository-specific data can be\nmoved into struct repository or related structures, while\nsubsystem-specific state should be localized appropriately. Passing\nrepository instances explicitly through function interfaces will improve\nmodularity, reduce hidden dependencies, and make the codebase easier to\nmaintain while moving Git closer to supporting multiple repositories safely\nwithin a single process.\n\nThe difficulty of this project is medium, and it is estimated to take 175\nto 350 hours.\n\nPre-GSOC:\n---------\n\nI first explored the Git codebase in December 2023, when I submitted a\nsmall patch fixing the wording of an error message that I noticed while\nbrowsing the source code. At that time I had recently started using Git and\nGitHub for version control in my projects, which sparked my curiosity about\nhow Git works internally. A few months ago, when I had some free time\nfrom college, I decided to start contributing to Git more actively. I built\nGit from source, read parts of the documentation, and familiarized myself\nwith the mailing list workflow. While going through the documentation, I\nnoticed a few inconsistencies in the MyFirstContribution page and submitted\npatches to fix them. I also completed a microproject involving a test\ncleanup, and later worked on adding a warning for a quiet fallback.\n\nDuring this process, I attempted to remove the usage of the_repository from\na file. After discussion on the mailing list [23], Phillip directed me\ntowards wt-status, which led me to explore parts of the codebase such as\nthe wt-status and worktree subsystems. Through this, I learned that such\nrefactors are generally more valuable in core library code. Following this\ndiscussion, I shifted my focus toward understanding the broader global\nstate refactoring effort. To better understand the project area, I studied\nprevious patches and blog posts by Ayush Chandekar and Olamide Bello,\nfollowed related discussions on the mailing list, and explored the relevant\nparts of the codebase. This motivated me to work further in this area and\nshaped my interest in this project.\n\nThe following is a list of my contributions, ordered from earliest to most\nrecent:\n\nPatches for Git:\n----------------\n\n* test-lib-functions.sh: fix test_grep fail message wording\n Status: Released in v2.43.1\n Mailing List: https://lore.kernel.org/git/20231203171956.771-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 37e8d795bed7b93d3f12bcdd3fbb86dfe57921e6\n Log: This was my first patch to Git in 2023. While browsing the\n source code and past issues, I noticed that even after\n the test_i18ngrep function was deprecated, an error message\n referring to test_i18ngrep was left behind. I updated\n the wording to correctly reference test_grep.\n\n* doc: MyFirstContribution: fix missing dependencies and clarify build steps\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260112195625.391821-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 81021871eaa8b16a892b9c8791a0c905ab26e342\n Log: While getting familiar with the codebase, I followed the\n MyFirstContribution documentation and encountered a few\n issues. Some include headers were missing, the synopsis\n format was incorrect, and the explanation for -j$(nproc)\n was absent. I submitted fixes to improve the clarity and\n correctness of the documentation.\n\n* t5500: simplify test implementation and fix git exit code suppression (Microproject)\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260121130012.888299-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: a824421d3644f39bfa8dfc75876db8ed1c7bcdbf\n Log: This was completed as a microproject for GSoC. Instead of\n constructing the pack protocol using a complex combination\n of here-docs and echo commands, the patch captures command\n outputs beforehand and uses the test-tool pkt-line pack\n helper to construct the protocol input in a temporary file\n before feeding it to git upload-pack.\n\n* show-index: add warning and wrap error messages with gettext\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260130153603.290196-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: ea39808a22714b8f61b9472de7ef467ced15efea,\n 227e2cc4e1415c4aeadceef527dd33e478ad5ec3\n Log: While exploring the code, I noticed a TODO comment suggesting\n automatic hash detection. After discussion on the mailing\n list, it was concluded that there was no future-proof\n approach to implement this until a new index file format\n came into use. Instead, an explicit warning was added rather\n than silently falling back to SHA-1. Additionally, several\n error messages were missing gettext wrapping, which was also\n fixed.\n\n* wt-status: reduce reliance on global state\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260218175654.66004-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: a7cd24de0b3b679c16ae3ee8215af06aeea1e6a3,\n 9d0d2ba217f3ceefb0315b556f012edb598b9724,\n 4631e22f925fa2af8d8548af97ee2215be101409\n Log: This has been the most significant patch series in my journey\n so far. It began with a suggestion from Phillip to clean up\n some the_repository usages in wt-status.c. I extended the\n effort to remove all usages of the_repository and\n the_hash_algo from the file. During review discussions, it\n was suggested that some worktree API cleanup should happen\n first, particularly regarding the representation of worktrees\n as NULL. Some related changes were later moved to a separate\n series, after which this refactoring proceeded.\n\n* worktree: change representation and usage of primary worktree\n Status: Merged into master after being continued by Phillip Wood [6]\n Mailing List: https://lore.kernel.org/git/20260213120529.15475-1-shreyanshpaliwalcmsmn@gmail.com/\n Log: This worktree API cleanup series started while I was working\n on wt-status. The intention was to modify the representation\n of the current worktree so that struct worktree would not be\n NULL. During discussion, Phillip clarified that NULL actually\n represents the current worktree rather than the primary\n worktree. Since Phillip already had a patch based on the right\n logic, he continued the series and it was eventually merged\n into master.\n\n* tree-diff: remove the usage of the_hash_algo global\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260220175331.1250726-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 1e50d839f8592daf364778298a61670c4b998654\n Log: This was a straightforward patch that removed the remaining\n usages of the global the_hash_algo in tree-diff.c by using the\n repository’s local instance instead.\n\n* send-email: UTF-8 encoding in subject line\n Status: Merged into master\n Mailing List: https://lore.kernel.org/git/20260228112210.270273-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: c52f085a477c8eece87821c5bbc035e5a900eb12\n Log: This patch was motivated by an issue I personally encountered\n while sending a GSoC discussion email [7]. Initially the\n change only modified the wording of the prompt, but after\n discussion on the mailing list it was extended to include\n proper validation to prevent invalid charset encodings from\n being used in git send-email and to reduce confusion.\n\n* Remove global state from editor.c\n Status: Awaiting further feedback / not yet picked up\n Mailing List: https://lore.kernel.org/git/20260310174519.676851-1-shreyanshpaliwalcmsmn@gmail.com/\n Log: This originated from a question I had about localizing\n editor_program in editor.c [7]. The patch had some\n discussion on whether editor_program state should become\n repository-scoped, since it can also be set via\n git config --local. Though it was approved by Karthik it\n has not been picked up by Junio yet and may be awaiting\n further review.\n\n* add-patch: use repository instance from add_p_state instead of the_repository\n Status: Needs Review\n Mailing List: https://lore.kernel.org/git/20260318090546.1213077-1-shreyanshpaliwalcmsmn@gmail.com/\n Commit: 3cfe355ca74aae5cf90a4eca73a341732b0eb456\n Log: This was also a straightforward change where the_repository\n was used instead of local instance of struct repo in add-patch\n config structs, but it had some changes that overlapped with a\n recent patch by Patrik. So I got to know the proper method of\n checking any overlapping changing and how to base your changes\n on top of them. I have sent the revised version, it needs to be\n replaced in the seen branch.\n\nPatches for git.github.io:\n--------------------------\n\n* SoC-2026-ideas: Remove an extra backtick\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/831\n Merge Commit: c1e4aa87a54430953eaa7355061139fdf1ff6796\n Log: Minor Typo fix.\n\n* rn-132: fixed 2 typos\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/832\n Merge Commit: 92876114d855d472ce2e0e5337e72a4b97b81681\n Log: Fixed typos in Git Rev News Edition 132.\n\n* Add Outreachy 2026 participant\n Status: merged into master\n PR Link: https://github.com/git/git.github.io/pull/836\n Merge Commit: 519170970ce7cf29661ee2707aa4e0411cbd2dac\n Log: Added Bello Caleb Olamide as Outreachy participant.\n\nI have also been involved in additional discussions on the Git mailing\nlist [8][9][10][11][26].\n\nHistory / Background:\n--------------------\n\nEfforts to reduce Git’s reliance on global state began as several\nsubsystems moved toward libification, enabling Git’s internal functionality\nto be reused as a library. Early examples include the libification of git\nmailinfo [12] and git apply [13], these large patch series exposed the\nlimitations of relying on global state and highlighted the need for better\nencapsulation of repository-related data. A key step was the introduction\nof struct repository through refactoring by Stefan Beller [14] and Brandon\nWilliams [15], which was motivated to centralize repository-related state\ninstead of relying on scattered global variables, improving code clarity\nwhile laying groundwork for future improvements such as safer\nmultithreading and handling submodules in the same process. Later work by\nPatrick further reduced reliance on the global the_repository in the config\n[16] and path [17] subsystems, consolidating several variables into\nenvironment.c so environment-related state could be managed in one place\n[18]. The macro #define USE_THE_REPOSITORY_VARIABLE was also introduced to\nhelp transition code away from implicit global repository access [19].\n\nDuring GSoC 2025, Ayush Chandekar [20] removed additional usages of\nthe_repository across the codebase and moved several global configuration\nvariables (such as core_preload_index and merge_log_config) into\nrepository-scoped structures. More recently, during Outreachy, Olamide\nBello improved configuration handling by introducing repo_config_values, a\nstructure linked to struct repository that stores repository-specific\nconfiguration values [21][22]. A supporting private structure,\nconfig_values_private, was added for initialization and internal handling.\nDiscussions around this work also highlighted an important design\nconstraint: directly moving globals into repository structures or\nintroducing lazy loading helpers can cause user experience regressions if\nconfiguration errors are detected later.\n\nThese efforts collectively form the foundation of the ongoing work to\ngradually remove Git’s reliance on global state and move toward a more\nmodular, repository-scoped architecture.\n\nProposed Plan:\n-------------\n\nI started exploring the codebase by browsing relevant files and identifying\nglobal variables by temporarily removing the USE_THE_REPOSITORY_VARIABLE\nmacro. My primary focus was on core library files rather than builtin code\n[23]. Through this exploration, I observed that a large number of files still\ndepend on the_repository.\n\nTo tackle this project systematically, I propose classifying these files into\ntwo categories:\n\n1. Files using the_repository or the_hash_algo where a repository\n instance already exists: These files rely on global variables even\n though a struct repository instance is available somewhere in the\n call stack. A simple example is my patch in tree-diff.c, where a\n repository instance was already available through struct diff_options\n *opt, but the_hash_algo was still used. I replaced it with\n opt->repo->hash_algo.\n\n In such cases, the refactor mainly involves passing the repository\n instance through the function call stack and replacing the global\n usages. If a repository instance is not directly available in the\n file, I will trace the callers and propagate it from higher levels in\n the call hierarchy.\n Examples of such files include alias.c, archive*.c, walker.c, and\n xdiff-interface.c. These typically require localized refactoring and\n are good candidates for incremental patches.\n\n2. Files relying on other global variables defined in environment.c:\n Some files depend on additional global variables that are parsed and\n accessed through environment.c. In these cases, there is no existing\n repository-scoped instance, making the refactor slightly more involved.\n\n Examples include wt-status.c (default_abbrev, comment_line_str) and\n apply.c (has_symlink, ignore_case, trust_executable_bit,\n apply_default_whitespace, apply_default_ignorewhitespace).\n For such variables, I will evaluate whether they should be moved into\n repository-scoped structures (e.g., repo_settings or\n repo_config_values), or instead be localized and passed explicitly\n where needed. The appropriate approach will depend on how widely the\n variable is used and whether it logically belongs in a\n multi-repository standpoint.\n\nI plan to begin with the first category, addressing straightforward\nrefactors file by file. In parallel, I will analyze and work on specific\ngroups of global variables from the second category, designing\nappropriate repository-scoped replacements while preserving the\noriginal parsing timing and availability of those variables.\n\nThe end goal is to remove reliance on global state and eventually eliminate\nthe USE_THE_REPOSITORY_VARIABLE macro from these files.\n\nProject Timeline:\n----------------\n\n* Community Bonding (Until May 24):\n - Discuss the project direction and design approaches with mentors.\n - Identify and prioritize two main areas of work:\n + files that rely on the_repository.\n + global variables defined in environment.c.\n - Study the previous patches by Olamide Bello and Ayush Chandekar\n in depth, and identify any remaining tasks while discussing\n their approaches and challenges with them.\n - Interact with all the people involved in this work to better\n understand design decisions and potential pitfalls.\n - Experiment with small RFC patches, if needed to validate approaches.\n\n* Coding period (May 25 - August 16):\n - Send patches for any remaining cleanup or refactoring related to\n git_default_config() and repo_config_values [22], as well as\n the worktree API [24], if any.\n - Identify straightforward refactors to remove usages of the_repository\n in files such as xdiff-interface.c, archive*.c, fsmonitor*.c etc.\n - Work file by file with the goal of eliminating\n #define USE_THE_REPOSITORY_VARIABLE by replacing global usages\n with explicit repository instances.\n - Concurrently maintain at least two parallel patch series:\n + Small / straightforward refactors and replacements like\n the_hash_algo or the_repository.\n + Larger structural refactors involving globals such as\n DEFAULT_ABBREV, comment_line_str etc.\n - Publish weekly or biweekly blog updates documenting progress and design\n decisions.\n\n* Final week (August 17 - August 24):\n - Address any remaining tasks or pending patches.\n - Receive final feedback from mentors and reviewers.\n - Prepare a detailed report summarizing the work completed during the project.\n\nBlogging:\n---------\n\nI believe blogging is an important part of any open-source project. It\nhelps others understand the ongoing work and also enables the contributor\nto develop a deeper understanding and keep a better track of their own\nprogress. I experienced this firsthand, early in my journey I was unsure\nabout various aspects, but reading the blogs of Ayush and Olamide Bello\ngave me valuable insight into the contributor perspective and their overall\nwork.\n\nWith the goal of helping future contributors in a similar way, I plan to\ndocument my journey and project progress through regular blog posts. I will\npublish updates on a weekly or biweekly basis, depending on the amount of\nmeaningful progress made. I have set up my blogging area on Medium, and my\nposts will be available at [25].\n\n\nAvailability:\n-------------\n\nThe main coding period runs from June to August. Most of June and July\ncoincide with my summer vacation, which allows me to dedicate significant\ntime to the project. My final exams are scheduled for May and will last\napproximately one week, but they will be completed before the coding period\nbegins and should not affect my availability.\n\nDuring June and July, I will be able to dedicate around 40 hours per week to\nthe project. In August, when my regular semester resumes, I expect to\ncontribute approximately 25–30 hours per week.\nI do not have any other exams, internships, or planned vacations during the\ncoding period. Apart from this project, I have no other major commitments\nfor the summer.\n\nI will keep the community regularly updated on my progress throughout the\nproject. My primary mode of communication will be email, and I will also be\navailable for calls or meetings if/when required. My preferred availability\nwindow is 13:00–19:00 UTC.\n\nPost GSoC:\n----------\n\nBeing part of the Git community and contributing to the codebase has been a\nvery valuable experience for me. The process of understanding Git’s internals,\nsubmitting patches, and receiving feedback on the mailing list has helped me\ngrow significantly as a developer. The feeling of working on code that is used\nby millions of developers and companies around the world is very rewarding.\n\nI plan to remain involved with the Git community even after GSoC by continuing\nto contribute patches, review code, and participate in discussions to help make\nGit better for end users. The work on refactoring Git’s global state is part of\na long-term effort, and I would love to continue working on it beyond the GSoC\ntimeline.\n\nI would also be happy to mentor, co-mentor, or volunteer in the future to help\nnew and upcoming contributors whenever I get the chance. I see GSoC as the\nstarting point of a long-term relationship with the Git community.\n\nClosing & Appreciation:\n-----------------------\n\nI would like to thank the Git community for the excellent documentation and the\nwelcoming environment. I am also grateful for the patience and guidance shown\nin the feedback and discussions on the mailing list by Junio, Phillip, Karthik,\nBen, and others, which have helped me improve my understanding and contributions.\n\nI also read blogs and proposals by Ayush, Lucas, Kousik Sanagavarapu, and Olamide\nBello, which provided valuable insights and helped shape my approach to contributing.\n\nThank you for reading my proposal :)\n\nReferences:\n-----------\n\n[1]- https://github.com/shreyp135/Alethea\n\n[2]- https://unstop.com/college-fests/impulse-2025-maharaja-agrasen-institute-of-technology-mait-new-delhi-348321\n\n[3]- https://cse.mait.ac.in/index.php/academics/9-computer-center/1249-iosd-mait-impulse-25\n\n[4]- https://iosd-web.vercel.app/\n\n[5]- https://www.linkedin.com/posts/code-for-goodtech_augtoberfest-c4gt2024-activity-7242923677032312834-XMul\n\n[6]- https://lore.kernel.org/git/cover.1771511192.git.phillip.wood@dunelm.org.uk/\n\n[7]- https://lore.kernel.org/git/20260304145823.189440-1-shreyanshpaliwalcmsmn@gmail.com/T/#m65b9b4547036991a7b7f3c861b9663428891f588\n\n[8]- https://lore.kernel.org/git/20260114143238.536312-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[9]- https://lore.kernel.org/git/20260115211609.17420-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[10]- https://lore.kernel.org/git/20260204111343.71975-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[11]- https://lore.kernel.org/git/20260205131132.44282-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[12]- https://lore.kernel.org/git/1444778207-859-1-git-send-email-gitster@pobox.com/\n\n[13]- https://lore.kernel.org/git/20160511131745.2914-1-chriscool@tuxfamily.org/\n\n[14]- https://lore.kernel.org/git/20180205235508.216277-1-sbeller@google.com/\n\n[15]- https://lore.kernel.org/git/20170531214417.38857-1-bmwill@google.com/\n\n[16]- https://lore.kernel.org/git/cover.1715339393.git.ps@pks.im/\n\n[17]- https://lore.kernel.org/git/20250206-b4-pks-path-drop-the-repository-v1-16-4e77f0313206@pks.im/\n\n[18]- https://lore.kernel.org/git/20250717-pks-config-wo-the-repository-v1-20-d888e4a17de1@pks.im/\n\n[19]- https://lore.kernel.org/git/cover.1718347699.git.ps@pks.im/\n\n[20]- https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html\n\n[21]- https://cloobtech.hashnode.dev/week-5-and-6-design-reviews-rfcs-and-refining-the-path-forward\n\n[22]- https://lore.kernel.org/all/cover.1771258573.git.belkid98@gmail.com/\n\n[23]- https://lore.kernel.org/git/7b5dd0c4-0ca0-458e-89db-621a70dac9ae@gmail.com/\n\n[24]- https://lore.kernel.org/git/20260217163909.55094-1-shreyanshpaliwalcmsmn@gmail.com/\n\n[25]- https://medium.com/@shreyanshpaliwal18\n\n[26]- https://lore.kernel.org/git/20260319092441.1283001-1-shreyanshpaliwalcmsmn@gmail.com/\n"}]}