{"thread":{"id":"63196","subject":"[GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","startedAt":"2025-03-26T05:26:32Z","lastAt":"2025-04-08T12:52:39Z","messageCount":13,"participants":["Ayush Chandekar","shejialuo","Karthik Nayak","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"515069","messageId":"20250326052602.265989-1-ayu.chandekar@gmail.com","threadId":"63196","inReplyTo":null,"subject":"[GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-03-26T05:26:00Z","receivedAt":"2025-03-26T05:26:32Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Hello,\nThis is my GSoC 2025 proposal for the project \"Refactoring in order to reduce Git’s global state\".\nYou can view docs version here: \nhttps://docs.google.com/document/d/1tJrtWxo1UGKChB3hu5eZ-ljm0FtU_fsv0TnIRwu3EKY/edit?usp=sharing\n\n---------\n\nRefactoring in order to reduce git’s state\n\nMy Information:\n---------------\n\nName: Ayush Chandekar\nEmail: ayu.chandekar@gmail.com\nMobile No: (+91) 9372496874\nEducation: UG Sophomore, IIT Roorkee\nGithub: https://github.com/ayu-ch\nBlog: https://ayu-ch.github.io\n\n\nAbout me:\n---------\n\nI'm Ayush Chandekar, a UG Sophomore studying at Indian Institute of\nTechnology, Roorkee. I like participating in various software development\nand tech-development endeavors, usually hackathons, CTFs, and projects at\nSDSLabs. SDSLabs is a student-run technical group that includes passionate\ndevelopers and designers interested in various fields and involved in multiple\nsoftware development projects that aim to foster a software development\nculture on campus. Being a part of this group has exposed me to different\nsoftware development methodologies, tools and frameworks and helped me become\ncomfortable contributing to an open-source project with multiple contributors.\nSome open-source contributions I made here are: [1], [2] & [3]\n\nI see this project as a meaningful opportunity to deepen my involvement in\nthe Git community and to build a foundation for continued contributions to\nopen source development in the future.\n\n\nOverview:\n---------\n\nGit currently uses a global object called `the_repository`, which refers to a\nsingle instance of `struct repository`. Many internal functions rely on this\nglobal object rather than accepting a `struct repository` as an explicit\nparameter. This design inherently assumes a single active repository,\nmaking it difficult to support multi-repository use cases and obstructing\nthe long-term goal of libification of Git.\n\nA key architectural limitation is that while `struct repository` encapsulates\nsome repository-specific information, many important environment variables\nand configuration settings that logically belong to a repository are still\nstored as global variables, primarily in `environment.c`, not within the\n`repository` struct. As a result, even if multiple repositories were to\nexist concurrently, they would still share this global state, leading to\nincorrect behavior, race conditions, or subtle bugs.\n\nThis project aims to refactor Git’s environment handling by relocating\nthese global variables into appropriate local contexts primarily into\n`struct repository` and `struct repo_settings`. This change will not\nonly make the environment state repository-specific, but also improve the\nmodularity and maintainability of the codebase. The work involves identifying\nenvironment-related global variables, designing a suitable structure to\nhouse them within the repository context, and updating all affected code\npaths accordingly.\n\nThe difficulty of this project is medium, and it is estimated to take \n175 to 350 hours.\n\n\nPre-GSOC:\n---------\n\nI started exploring Git’s codebase and documentation around the end of\nJanuary, familiarizing myself with its structure and development practices. I\nsubmitted a microproject, which helped me navigate the code and contribution\nworkflow.\n\nAfter selecting the project on refactoring Git’s state, I studied the\nsurrounding code and reviewed past patches ([4], [5], [6], [7], [8] & [9])\nto understand the reasoning behind previous changes. To better prepare\nfor the GSoC timeline, I also submitted a patch related to the project,\ngaining hands-on experience with both the implementation details and the\nsubmission process.\n\n\nPatches:\n--------\n\n+ (Microproject) t6423: fix suppression of Git’s exit code in tests\n\tThread:\n\thttps://public-inbox.org/git/20250202120926.322417-1-ayu.chandekar@gmail.com/\n\tStatus: Merged into master \n\tCommit Hash: 7c1d34fe5d1229362f2c3ecf2d493167a1f555a2 \n\tDescription: Instead of executing a Git command as the upstream component of\n\t\t\t\t a pipe, which can result in the exit status being lost, redirect\n\t\t\t\t its output to a file and then process that file in two steps to\n\t\t\t\t ensure the exit status is properly preserved.\n\n+ midx: implement progress reporting for QSORT operation\n\tThread:\n\thttps://public-inbox.org/git/20250210074623.136599-1-ayu.chandekar@gmail.com/\n\tStatus: Dropped \n\tDescription: Add progress reporting during the QSORT operation in \n\t\t\t\t multi-pack-index verification. While going through the code, \n\t\t\t\t I found this TODO, which I thought was interesting however my \n\t\t\t\t approach assumed that the qsort() operation processes elements\n\t\t\t\t in a structured order, which isn't guaranteed.\n\n+ Stop depending on `the_repository` for core.attributesfile\n\tThread:\n\thttps://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@gmail.com/\n\tStatus: WIP, needs more discussion.  \n\tDescription: This patch refactors access to the `core.attributesfiles` \n\t\t\t\t configuration by moving it into the `repo_settings` struct.\n\t\t\t\t It eliminates the global variable `git_attributes_file` and \n\t\t\t\t updates relevant code paths to pass the `struct repository`\n\t\t\t\t as a parameter.\n\n\nProposed Plan:\n--------------\n\nI have been reviewing global variables across the codebase to understand their\ndependencies and impact. To do this, I examined `config.c` and cross-referenced\nit with `environment.c` to see how these variables are currently managed. The\ngoal of this project is to eliminate global variables by moving their\nconfigurations into repository-specific settings. This involves:\n\n-   Identifying all occurrences of these global variables.\n\n-   Removing dependencies on `the_repository`.\n\n-   Updating function signatures to pass `struct repository` explicitly.\n\n-   Replacing global variable references with repository-scoped configurations.\n\nInstead of adding all variables directly into `repo_settings`, we can group\nrelated variables into specialized structs (e.g., `performance_config`,\n`behaviour_config`, `whitespace_config`) and embed these within `repo_settings`.\nThis approach ensures a more modular and maintainable design while keeping \n`repo_settings` manageable.\n\nI have also created a diagram explaining this structure in [10].\n\nWith this approach, I can structure the patch series by grouping the refactoring \nof related variables within specific structs. This will help maintain a clean and\norganized codebase while also making the development and review process more \nsystematic and efficient.\n\nOne key challenge is determining which variables should be part of\n`repo_settings` and which should remain separate. While working on the patch to\nrefactor access to `core.attributesfile`, I received feedback from Junio that not\nall global variables should be blindly moved into the `repo_settings` struct.\nThis reinforced the need to carefully assess which variables belong in `repo_settings`\nand which should be handled differently.\n\nThis plan is flexible and may be refined through multiple iterations as I receive\nfeedback from the community and reviewers.\n\nTimeline:\n---------\n\nPre-GSOC: \n(Until 8 May) \n-\tExplore the codebase more, focusing on environment-related code paths.\n-\tDocument how each global variable is used and how it can be moved to \n\trepository settings.  \n-\tStudy Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n\n----------\n\nCommunity Bonding: \n(May 8 - June 1) \n-\tEngage with mentors to discuss different environment variables, their \n\tdependencies, and the best approach for refactoring.\n-\tFinalize an implementation plan based on discussions.\n-\tSince I will be on summer vacation, I can start coding early and make progress \n\ton the project.\n\n----------\n\nCoding Period: \n(June 2 - August 25) \n-\tRefactor global variables, replacing them with repository-scoped \n\tconfigurations.  \n-\tModify function signatures to pass `struct repository` explicitly instead\n\tof relying on `the_repository`.\n-\tCategorize variables into specialized structs to improve modularity and\n\tmaintainability.  \n-\tContinuously submit patches for review and incorporate feedback from mentors\n\tand the community.  \n-\tI plan to write weekly blogs which will document what I did in the whole \n\tweek.\n\n----------\n\nFinal Week: \n(August 25 - September 1) \n-\tWrite a detailed report on the entire project.  \n-\tFix bugs if any.  \n-\tReflect on the project, noting challenges faced and lessons learned.\n\n\nBlogging:\n---------\n\nI have also set up a blogging page at [11]. While reading blogs from previous\nGSoC contributors, I found them useful in understanding the challenges\nthey faced and how they approached their projects. Their experiences gave\nme a better idea of what to expect and how to navigate the development\nprocess. Inspired by this, I decided to start my own blog to document my\njourney throughout GSoC. This will not only help me track my own progress but\nalso serve as a resource for future contributors who might work on similar\nprojects. I plan to share updates on my work, challenges encountered and\ninsights gained from discussions with mentors and the community.\n\nAdditionally, I hope my blog encourages more people to contribute to open\nsource by providing a transparent look into the development process. Writing\nabout my experience will also help me reflect on my work and improve my\nability to communicate technical ideas effectively.\n\nI liked the format and structure of Chandra's blog, so I decided to use the\nsame template for my own blogging page.\n\n\nAvailability:\n-------------\n\nAs a college student, I intend to utilise my summer breaks from May to July\nto work on the project. After completing my University exams in April, I can\nstart working in May. I can dedicate 40 hours a week from May to July, while\nin August after the classes commence, I can dedicate about 25 hours a week.\n\nThere are no exams or planned vacations throughout the coding period. Besides\nthis project, I have no commitments/vacations planned for the summer. I shall\nkeep my status posted to all the community members and maintain transparency\nin the project.\n\n\nPost-GSOC:\n----------\n\nBeyond contributing code, I strongly believe in giving back to the community\nand helping others grow. Open source thrives on mentorship, knowledge sharing,\nand long-term involvement, and I would love to continue contributing even\nafter GSoC ends.\n\nI have always valued mentorship, both as a mentee and as someone who enjoys\nguiding others. If given the opportunity, I would be more than happy to\nmentor/co-mentor future GSoC contributors. By staying involved in the\ncommunity, whether through contributing, reviewing patches, or mentoring,\nI hope to help sustain and expand the project’s reach. I look at GSoC as not \njust as a one-time contribution but as a step toward a longer-term relationship\nwith open source.\n\nI will continue to be involved with Git even after GSoC by contributing patches,\nreviewing code, and participating in discussions. My work on refactoring Git’s \nstate aligns with long-term improvements to the codebase, and I plan to keep \nrefining it beyond the program. I see GSoC as just the beginning of my journey\nwith Git.\n\nAppreciation:\n-------------\n\nI appreciate the Git community for its excellent documentation, which made it \nmuch easier for me to understand Git in depth. The well-structured resources \nhelped me navigate the codebase and gain a deeper understanding of how Git \nworks internally.\n\nBeyond the documentation, I am also grateful for how welcoming and supportive \nthe community has been. Whether through discussions on the mailing list or \nfeedback on my patches, the information and guidance I received made my \nexperience even better.\n\nAdditionally, I read the blogs and proposals of Chandra, Jialuo, and Ghanashyam, \nwhich provided valuable insights into their journeys and helped me shape my \nown approach to contributing.\n\nThanks for reviewing this proposal.\n\nReferences:\n-----------\n\n[1] https://github.com/sdslabs/beast/pull/374\n\n[2] https://github.com/sdslabs/beast/tree/add-teams-with-hint\n\n[3] https://github.com/sdslabs/playCTF/pull/177\n\n[4] https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n\n[5] https://public-inbox.org/git/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/\n\n[6] https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/\n\n[7] https://public-inbox.org/git/pull.1829.git.1731653548549.gitgitgadget@gmail.com/#t\n\n[8] https://public-inbox.org/git/cover.1733236936.git.karthik.188@gmail.com/\n\n[9] https://public-inbox.org/git/cover.1724923648.git.ps@pks.im/\n\n[10] https://www.mermaidchart.com/raw/327324ea-af1d-4a98-8bff-254479b3a79c?theme=light&version=v0.1&format=svg\n\n[11] https://ayu-ch.github.io\n"},{"id":"515230","messageId":"Z-ae2l6fkurPNuPe@ArchLinux","threadId":"63196","inReplyTo":"20250326052602.265989-1-ayu.chandekar@gmail.com","subject":"Re: [GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","fromName":"shejialuo","fromEmail":"shejialuo@gmail.com","sentAt":"2025-03-28T13:06:34Z","receivedAt":"2025-03-28T13:06:32Z","isPatch":false,"sender":{"key":"shejialuo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56911263?v=4"},"body":"On Wed, Mar 26, 2025 at 10:56:00AM +0530, Ayush Chandekar wrote:\n> Hello,\n> This is my GSoC 2025 proposal for the project \"Refactoring in order to reduce Git’s global state\".\n> You can view docs version here: \n> https://docs.google.com/document/d/1tJrtWxo1UGKChB3hu5eZ-ljm0FtU_fsv0TnIRwu3EKY/edit?usp=sharing\n> \n> ---------\n> \n> Refactoring in order to reduce git’s state\n> \n> My Information:\n> ---------------\n> \n> Name: Ayush Chandekar\n> Email: ayu.chandekar@gmail.com\n> Mobile No: (+91) 9372496874\n> Education: UG Sophomore, IIT Roorkee\n> Github: https://github.com/ayu-ch\n> Blog: https://ayu-ch.github.io\n> \n> \n> About me:\n> ---------\n> \n> I'm Ayush Chandekar, a UG Sophomore studying at Indian Institute of\n> Technology, Roorkee. I like participating in various software development\n> and tech-development endeavors, usually hackathons, CTFs, and projects at\n> SDSLabs. SDSLabs is a student-run technical group that includes passionate\n> developers and designers interested in various fields and involved in multiple\n> software development projects that aim to foster a software development\n> culture on campus. Being a part of this group has exposed me to different\n> software development methodologies, tools and frameworks and helped me become\n> comfortable contributing to an open-source project with multiple contributors.\n> Some open-source contributions I made here are: [1], [2] & [3]\n> \n> I see this project as a meaningful opportunity to deepen my involvement in\n> the Git community and to build a foundation for continued contributions to\n> open source development in the future.\n> \n> \n> Overview:\n> ---------\n> \n> Git currently uses a global object called `the_repository`, which refers to a\n> single instance of `struct repository`. Many internal functions rely on this\n> global object rather than accepting a `struct repository` as an explicit\n> parameter. This design inherently assumes a single active repository,\n> making it difficult to support multi-repository use cases and obstructing\n> the long-term goal of libification of Git.\n> \n> A key architectural limitation is that while `struct repository` encapsulates\n> some repository-specific information, many important environment variables\n> and configuration settings that logically belong to a repository are still\n> stored as global variables, primarily in `environment.c`, not within the\n> `repository` struct. As a result, even if multiple repositories were to\n> exist concurrently, they would still share this global state, leading to\n> incorrect behavior, race conditions, or subtle bugs.\n> \n> This project aims to refactor Git’s environment handling by relocating\n> these global variables into appropriate local contexts primarily into\n> `struct repository` and `struct repo_settings`. This change will not\n\nI think we could just improve this statement better. Some global\nvariables may only apply to one subsystem or two subsystems. In such\nsituations, we may just put the global variable into their own context\nbut not the \"struct repository\" or \"struct repo_settings\".\n\n> only make the environment state repository-specific, but also improve the\n> modularity and maintainability of the codebase. The work involves identifying\n> environment-related global variables, designing a suitable structure to\n> house them within the repository context, and updating all affected code\n> paths accordingly.\n> \n> The difficulty of this project is medium, and it is estimated to take \n> 175 to 350 hours.\n> \n> \n> Pre-GSOC:\n> ---------\n> \n> I started exploring Git’s codebase and documentation around the end of\n> January, familiarizing myself with its structure and development practices. I\n> submitted a microproject, which helped me navigate the code and contribution\n> workflow.\n> \n> After selecting the project on refactoring Git’s state, I studied the\n> surrounding code and reviewed past patches ([4], [5], [6], [7], [8] & [9])\n> to understand the reasoning behind previous changes. To better prepare\n> for the GSoC timeline, I also submitted a patch related to the project,\n> gaining hands-on experience with both the implementation details and the\n> submission process.\n> \n> \n> Patches:\n> --------\n> \n> + (Microproject) t6423: fix suppression of Git’s exit code in tests\n> \tThread:\n> \thttps://public-inbox.org/git/20250202120926.322417-1-ayu.chandekar@gmail.com/\n> \tStatus: Merged into master \n> \tCommit Hash: 7c1d34fe5d1229362f2c3ecf2d493167a1f555a2 \n> \tDescription: Instead of executing a Git command as the upstream component of\n> \t\t\t\t a pipe, which can result in the exit status being lost, redirect\n> \t\t\t\t its output to a file and then process that file in two steps to\n> \t\t\t\t ensure the exit status is properly preserved.\n> \n> + midx: implement progress reporting for QSORT operation\n> \tThread:\n> \thttps://public-inbox.org/git/20250210074623.136599-1-ayu.chandekar@gmail.com/\n> \tStatus: Dropped \n> \tDescription: Add progress reporting during the QSORT operation in \n> \t\t\t\t multi-pack-index verification. While going through the code, \n> \t\t\t\t I found this TODO, which I thought was interesting however my \n> \t\t\t\t approach assumed that the qsort() operation processes elements\n> \t\t\t\t in a structured order, which isn't guaranteed.\n> \n> + Stop depending on `the_repository` for core.attributesfile\n> \tThread:\n> \thttps://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@gmail.com/\n> \tStatus: WIP, needs more discussion.  \n> \tDescription: This patch refactors access to the `core.attributesfiles` \n> \t\t\t\t configuration by moving it into the `repo_settings` struct.\n> \t\t\t\t It eliminates the global variable `git_attributes_file` and \n> \t\t\t\t updates relevant code paths to pass the `struct repository`\n> \t\t\t\t as a parameter.\n> \n> \n> Proposed Plan:\n> --------------\n> \n> I have been reviewing global variables across the codebase to understand their\n> dependencies and impact. To do this, I examined `config.c` and cross-referenced\n> it with `environment.c` to see how these variables are currently managed. The\n> goal of this project is to eliminate global variables by moving their\n> configurations into repository-specific settings. This involves:\n> \n> -   Identifying all occurrences of these global variables.\n> \n> -   Removing dependencies on `the_repository`.\n> \n> -   Updating function signatures to pass `struct repository` explicitly.\n> \n\nWhen reading this, I feel a little wired because I think in [1], you\nhave already realized that we should move some global variables to some\nspecific subsystems.\n\n[1] https://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@gmail.com/ \n\n> -   Replacing global variable references with repository-scoped configurations.\n> \n> Instead of adding all variables directly into `repo_settings`, we can group\n> related variables into specialized structs (e.g., `performance_config`,\n> `behaviour_config`, `whitespace_config`) and embed these within `repo_settings`.\n> This approach ensures a more modular and maintainable design while keeping \n> `repo_settings` manageable.\n> \n> I have also created a diagram explaining this structure in [10].\n> \n> With this approach, I can structure the patch series by grouping the refactoring \n> of related variables within specific structs. This will help maintain a clean and\n> organized codebase while also making the development and review process more \n> systematic and efficient.\n> \n\nYes, it's a good idea to use sub-structure to make the code be cleaner.\nHowever, from my own experience when being a GSoC student, we should not\nconsider about this due to that we will over-engineer this.\n\nYou need a lot of time and effort to convince the community why the\ndesign is good and why we should put this variable into this\nsub-structure.\n\nInstead, you'd better focus on which variables you want to remove\nfirstly. And how do you try to remove them with some simple steps. This\nwould make you more concentrate on the jobs you need to do and reduce\nthe risk.\n\n> One key challenge is determining which variables should be part of\n> `repo_settings` and which should remain separate. While working on the patch to\n> refactor access to `core.attributesfile`, I received feedback from Junio that not\n> all global variables should be blindly moved into the `repo_settings` struct.\n> This reinforced the need to carefully assess which variables belong in `repo_settings`\n> and which should be handled differently.\n> \n\nYes, this is correct. I somehow think whether we should put this\nparagraph into Pre-GSoC part? I think that you have found this when\nadding a patch to remove one global variable. And thus by communicating\nwith the community, you have further understood that the requirement and\nthe detail of this project.\n\nAnd in your plan, you should just say that we need to do this. Would\nthis be better?\n\n> This plan is flexible and may be refined through multiple iterations as I receive\n> feedback from the community and reviewers.\n> \n> Timeline:\n> ---------\n> \n> Pre-GSOC: \n> (Until 8 May) \n> -\tExplore the codebase more, focusing on environment-related code paths.\n> -\tDocument how each global variable is used and how it can be moved to \n> \trepository settings.  \n> -\tStudy Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n> \n> ----------\n> \n> Community Bonding: \n> (May 8 - June 1) \n> -\tEngage with mentors to discuss different environment variables, their \n> \tdependencies, and the best approach for refactoring.\n> -\tFinalize an implementation plan based on discussions.\n> -\tSince I will be on summer vacation, I can start coding early and make progress \n> \ton the project.\n> \n> ----------\n> \n> Coding Period: \n> (June 2 - August 25) \n> -\tRefactor global variables, replacing them with repository-scoped \n> \tconfigurations.  \n> -\tModify function signatures to pass `struct repository` explicitly instead\n> \tof relying on `the_repository`.\n> -\tCategorize variables into specialized structs to improve modularity and\n> \tmaintainability.  \n\nAs I have said, this is a high-risk task. Categorization needs many\niterations. And we may do this after GSoC.\n\n> -\tContinuously submit patches for review and incorporate feedback from mentors\n> \tand the community.  \n> -\tI plan to write weekly blogs which will document what I did in the whole \n> \tweek.\n> \n> ----------\n> \n> Final Week: \n> (August 25 - September 1) \n> -\tWrite a detailed report on the entire project.  \n> -\tFix bugs if any.  \n> -\tReflect on the project, noting challenges faced and lessons learned.\n> \n> \n> Blogging:\n> ---------\n> \n> I have also set up a blogging page at [11]. While reading blogs from previous\n> GSoC contributors, I found them useful in understanding the challenges\n> they faced and how they approached their projects. Their experiences gave\n> me a better idea of what to expect and how to navigate the development\n> process. Inspired by this, I decided to start my own blog to document my\n> journey throughout GSoC. This will not only help me track my own progress but\n> also serve as a resource for future contributors who might work on similar\n> projects. I plan to share updates on my work, challenges encountered and\n> insights gained from discussions with mentors and the community.\n> \n> Additionally, I hope my blog encourages more people to contribute to open\n> source by providing a transparent look into the development process. Writing\n> about my experience will also help me reflect on my work and improve my\n> ability to communicate technical ideas effectively.\n> \n> I liked the format and structure of Chandra's blog, so I decided to use the\n> same template for my own blogging page.\n> \n> \n> Availability:\n> -------------\n> \n> As a college student, I intend to utilise my summer breaks from May to July\n> to work on the project. After completing my University exams in April, I can\n> start working in May. I can dedicate 40 hours a week from May to July, while\n> in August after the classes commence, I can dedicate about 25 hours a week.\n> \n> There are no exams or planned vacations throughout the coding period. Besides\n> this project, I have no commitments/vacations planned for the summer. I shall\n> keep my status posted to all the community members and maintain transparency\n> in the project.\n> \n> \n> Post-GSOC:\n> ----------\n> \n> Beyond contributing code, I strongly believe in giving back to the community\n> and helping others grow. Open source thrives on mentorship, knowledge sharing,\n> and long-term involvement, and I would love to continue contributing even\n> after GSoC ends.\n> \n> I have always valued mentorship, both as a mentee and as someone who enjoys\n> guiding others. If given the opportunity, I would be more than happy to\n> mentor/co-mentor future GSoC contributors. By staying involved in the\n> community, whether through contributing, reviewing patches, or mentoring,\n> I hope to help sustain and expand the project’s reach. I look at GSoC as not \n> just as a one-time contribution but as a step toward a longer-term relationship\n> with open source.\n> \n> I will continue to be involved with Git even after GSoC by contributing patches,\n> reviewing code, and participating in discussions. My work on refactoring Git’s \n> state aligns with long-term improvements to the codebase, and I plan to keep \n> refining it beyond the program. I see GSoC as just the beginning of my journey\n> with Git.\n> \n> Appreciation:\n> -------------\n> \n> I appreciate the Git community for its excellent documentation, which made it \n> much easier for me to understand Git in depth. The well-structured resources \n> helped me navigate the codebase and gain a deeper understanding of how Git \n> works internally.\n> \n> Beyond the documentation, I am also grateful for how welcoming and supportive \n> the community has been. Whether through discussions on the mailing list or \n> feedback on my patches, the information and guidance I received made my \n> experience even better.\n> \n> Additionally, I read the blogs and proposals of Chandra, Jialuo, and Ghanashyam, \n> which provided valuable insights into their journeys and helped me shape my \n> own approach to contributing.\n\nI'm happy that my blogs help you.\n\n> \n> Thanks for reviewing this proposal.\n> \n\nThanks for your proposal!\n\n> References:\n> -----------\n> \n> [1] https://github.com/sdslabs/beast/pull/374\n> \n> [2] https://github.com/sdslabs/beast/tree/add-teams-with-hint\n> \n> [3] https://github.com/sdslabs/playCTF/pull/177\n> \n> [4] https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n> \n> [5] https://public-inbox.org/git/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/\n> \n> [6] https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/\n> \n> [7] https://public-inbox.org/git/pull.1829.git.1731653548549.gitgitgadget@gmail.com/#t\n> \n> [8] https://public-inbox.org/git/cover.1733236936.git.karthik.188@gmail.com/\n> \n> [9] https://public-inbox.org/git/cover.1724923648.git.ps@pks.im/\n> \n> [10] https://www.mermaidchart.com/raw/327324ea-af1d-4a98-8bff-254479b3a79c?theme=light&version=v0.1&format=svg\n> \n> [11] https://ayu-ch.github.io\n\nJialuo\n"},{"id":"515267","messageId":"CAE7as+b8qZFEcaH9eJcQnuhZOSW+hfAMiPUBXNPj9x1L7rcXVg@mail.gmail.com","threadId":"63196","inReplyTo":"Z-ae2l6fkurPNuPe@ArchLinux","subject":"Re: [GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-03-29T09:54:05Z","receivedAt":"2025-03-29T09:54:17Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"> > This project aims to refactor Git’s environment handling by relocating\n> > these global variables into appropriate local contexts primarily into\n> > `struct repository` and `struct repo_settings`. This change will not\n>\n> I think we could just improve this statement better. Some global\n> variables may only apply to one subsystem or two subsystems. In such\n> situations, we may just put the global variable into their own context\n> but not the \"struct repository\" or \"struct repo_settings\".\n\nRight, I was generalizing in my statement, but I agree that some\nglobal variables\nmay belong in subsystem-specific contexts rather than `struct repository` or\n`struct repo_settings`. I'll make sure to account for that distinction\nin my proposal\nand implementation.\n\n> >\n> > Proposed Plan:\n> > --------------\n> >\n> > I have been reviewing global variables across the codebase to understand their\n> > dependencies and impact. To do this, I examined `config.c` and cross-referenced\n> > it with `environment.c` to see how these variables are currently managed. The\n> > goal of this project is to eliminate global variables by moving their\n> > configurations into repository-specific settings. This involves:\n> >\n> > -   Identifying all occurrences of these global variables.\n> >\n> > -   Removing dependencies on `the_repository`.\n> >\n> > -   Updating function signatures to pass `struct repository` explicitly.\n> >\n>\n> When reading this, I feel a little wired because I think in [1], you\n> have already realized that we should move some global variables to some\n> specific subsystems.\n>\n> [1] https://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@gmail.com/\n>\n\nI see your point. I was generalizing again, but I’ll make sure to\nclarify this distinction\nin my proposal. Thanks for pointing it out!\n\n> > -   Replacing global variable references with repository-scoped configurations.\n> >\n> > Instead of adding all variables directly into `repo_settings`, we can group\n> > related variables into specialized structs (e.g., `performance_config`,\n> > `behaviour_config`, `whitespace_config`) and embed these within `repo_settings`.\n> > This approach ensures a more modular and maintainable design while keeping\n> > `repo_settings` manageable.\n> >\n> > I have also created a diagram explaining this structure in [10].\n> >\n> > With this approach, I can structure the patch series by grouping the refactoring\n> > of related variables within specific structs. This will help maintain a clean and\n> > organized codebase while also making the development and review process more\n> > systematic and efficient.\n> >\n>\n> Yes, it's a good idea to use sub-structure to make the code be cleaner.\n> However, from my own experience when being a GSoC student, we should not\n> consider about this due to that we will over-engineer this.\n>\n> You need a lot of time and effort to convince the community why the\n> design is good and why we should put this variable into this\n> sub-structure.\n>\n> Instead, you'd better focus on which variables you want to remove\n> firstly. And how do you try to remove them with some simple steps. This\n> would make you more concentrate on the jobs you need to do and reduce\n> the risk.\n>\n\nThat makes sense. My intent was to provide a structured approach, but\nI could see how it\nit may introduce unnecessary complexity at this stage. I'll focus on\nidentifying and managing\nthe global variables before considering additional structuring. I\nthink this is something which\ncan be done at the end of the project. That is, once all the variables\nare handled, they can\nthen be set into specific structures, if needed.\n\n> > One key challenge is determining which variables should be part of\n> > `repo_settings` and which should remain separate. While working on the patch to\n> > refactor access to `core.attributesfile`, I received feedback from Junio that not\n> > all global variables should be blindly moved into the `repo_settings` struct.\n> > This reinforced the need to carefully assess which variables belong in `repo_settings`\n> > and which should be handled differently.\n> >\n>\n> Yes, this is correct. I somehow think whether we should put this\n> paragraph into Pre-GSoC part? I think that you have found this when\n> adding a patch to remove one global variable. And thus by communicating\n> with the community, you have further understood that the requirement and\n> the detail of this project.\n\nYep, since I encountered this while working on the patch, it fits well\nin the Pre-GSoC section.\nMoving it there would better show how I learned more about the\nproject's scope through\ncommunity feedback.\n\n>\n> And in your plan, you should just say that we need to do this. Would\n> this be better?\n>\nSo, I should remove all the categorization stuff and just say that I\nwould focus on\neach variable, discuss in the community whether it should belong in the struct\nrepo_settings/repo or not while sending patches?\nI felt that keeping it general might seem vague, but that's the nature\nof the project. Every variable\nis unique and would need a different approach and outlining the\napproach of each variable\nin the proposal is not very feasible, as these decisions need to\nhappen collaboratively through\ndiscussions in the community.\n\nShould I still mention that once the project is complete, we could\nconsider structuring related\nstuff if the community sees value in it.\n\n> > This plan is flexible and may be refined through multiple iterations as I receive\n> > feedback from the community and reviewers.\n> >\n> > Timeline:\n> > ---------\n> >\n> > Pre-GSOC:\n> > (Until 8 May)\n> > -     Explore the codebase more, focusing on environment-related code paths.\n> > -     Document how each global variable is used and how it can be moved to\n> >       repository settings.\n> > -     Study Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n> >\n> > ----------\n> >\n> > Community Bonding:\n> > (May 8 - June 1)\n> > -     Engage with mentors to discuss different environment variables, their\n> >       dependencies, and the best approach for refactoring.\n> > -     Finalize an implementation plan based on discussions.\n> > -     Since I will be on summer vacation, I can start coding early and make progress\n> >       on the project.\n> >\n> > ----------\n> >\n> > Coding Period:\n> > (June 2 - August 25)\n> > -     Refactor global variables, replacing them with repository-scoped\n> >       configurations.\n> > -     Modify function signatures to pass `struct repository` explicitly instead\n> >       of relying on `the_repository`.\n> > -     Categorize variables into specialized structs to improve modularity and\n> >       maintainability.\n>\n> As I have said, this is a high-risk task. Categorization needs many\n> iterations. And we may do this after GSoC.\n\nYep, will update that.\n\nThanks for your review, again:)\n\nAyush\n"},{"id":"515364","messageId":"Z-qkFmc9xJXXTzut@ArchLinux","threadId":"63196","inReplyTo":"CAE7as+b8qZFEcaH9eJcQnuhZOSW+hfAMiPUBXNPj9x1L7rcXVg@mail.gmail.com","subject":"Re: [GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","fromName":"shejialuo","fromEmail":"shejialuo@gmail.com","sentAt":"2025-03-31T14:17:58Z","receivedAt":"2025-03-31T14:17:53Z","isPatch":false,"sender":{"key":"shejialuo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56911263?v=4"},"body":"On Sat, Mar 29, 2025 at 03:24:05PM +0530, Ayush Chandekar wrote:\n\n[snip]\n\n> > > One key challenge is determining which variables should be part of\n> > > `repo_settings` and which should remain separate. While working on the patch to\n> > > refactor access to `core.attributesfile`, I received feedback from Junio that not\n> > > all global variables should be blindly moved into the `repo_settings` struct.\n> > > This reinforced the need to carefully assess which variables belong in `repo_settings`\n> > > and which should be handled differently.\n> > >\n> >\n> > Yes, this is correct. I somehow think whether we should put this\n> > paragraph into Pre-GSoC part? I think that you have found this when\n> > adding a patch to remove one global variable. And thus by communicating\n> > with the community, you have further understood that the requirement and\n> > the detail of this project.\n> \n> Yep, since I encountered this while working on the patch, it fits well\n> in the Pre-GSoC section.\n> Moving it there would better show how I learned more about the\n> project's scope through\n> community feedback.\n> \n\nYes, this is my intention. This represents your ability where you\ninteract with the community and get feedback. And this is what we want\nto see.\n\n> >\n> > And in your plan, you should just say that we need to do this. Would\n> > this be better?\n> >\n> So, I should remove all the categorization stuff and just say that I\n> would focus on\n> each variable, discuss in the community whether it should belong in the struct\n> repo_settings/repo or not while sending patches?\n\nI think you should put the categorization stuff into after-GSoC part.\nWell, I don't think you could focus on _each_ variable. This is\nimpossible for you to talk about the way for _each_ variable. I somehow\nthink that you could just write the proposal about how to handle one or\ntwo global variables.\n\nYou already touch one setting \"core.attributesfile\" right? You may just\nelaborate more in the proposal.\n\n> I felt that keeping it general might seem vague, but that's the nature\n> of the project. Every variable\n> is unique and would need a different approach and outlining the\n> approach of each variable\n> in the proposal is not very feasible, as these decisions need to\n> happen collaboratively through\n> discussions in the community.\n> \n\nYes, so you could firstly give how you want to handle the global\nvariables from top. And give some concrete examples to demonstrate your\nidea.\n\n> Should I still mention that once the project is complete, we could\n> consider structuring related\n> stuff if the community sees value in it.\n> \n\nYou could, mention this in after GSoC part.\n\n> > > This plan is flexible and may be refined through multiple iterations as I receive\n> > > feedback from the community and reviewers.\n> > >\n> > > Timeline:\n> > > ---------\n> > >\n> > > Pre-GSOC:\n> > > (Until 8 May)\n> > > -     Explore the codebase more, focusing on environment-related code paths.\n> > > -     Document how each global variable is used and how it can be moved to\n> > >       repository settings.\n> > > -     Study Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n> > >\n> > > ----------\n> > >\n> > > Community Bonding:\n> > > (May 8 - June 1)\n> > > -     Engage with mentors to discuss different environment variables, their\n> > >       dependencies, and the best approach for refactoring.\n> > > -     Finalize an implementation plan based on discussions.\n> > > -     Since I will be on summer vacation, I can start coding early and make progress\n> > >       on the project.\n> > >\n> > > ----------\n> > >\n> > > Coding Period:\n> > > (June 2 - August 25)\n> > > -     Refactor global variables, replacing them with repository-scoped\n> > >       configurations.\n> > > -     Modify function signatures to pass `struct repository` explicitly instead\n> > >       of relying on `the_repository`.\n> > > -     Categorize variables into specialized structs to improve modularity and\n> > >       maintainability.\n> >\n> > As I have said, this is a high-risk task. Categorization needs many\n> > iterations. And we may do this after GSoC.\n> \n> Yep, will update that.\n> \n> Thanks for your review, again:)\n> \n> Ayush\n\nThanks,\nJialuo\n"},{"id":"515369","messageId":"CAE7as+ZF6ARDQjGTyhjP7JZqhpbvZeouKGZA+tdZur_-8a5EXw@mail.gmail.com","threadId":"63196","inReplyTo":"Z-qkFmc9xJXXTzut@ArchLinux","subject":"Re: [GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-03-31T15:04:33Z","receivedAt":"2025-03-31T15:04:45Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"> > Yep, since I encountered this while working on the patch, it fits well\n> > in the Pre-GSoC section.\n> > Moving it there would better show how I learned more about the\n> > project's scope through\n> > community feedback.\n> >\n>\n> Yes, this is my intention. This represents your ability where you\n> interact with the community and get feedback. And this is what we want\n> to see.\n>\n\nGot it!\n\n> > So, I should remove all the categorization stuff and just say that I\n> > would focus on\n> > each variable, discuss in the community whether it should belong in the struct\n> > repo_settings/repo or not while sending patches?\n>\n> I think you should put the categorization stuff into after-GSoC part.\n> Well, I don't think you could focus on _each_ variable. This is\n> impossible for you to talk about the way for _each_ variable. I somehow\n> think that you could just write the proposal about how to handle one or\n> two global variables.\n>\n\nRight, I can do that.\n\n> You already touch one setting \"core.attributesfile\" right? You may just\n> elaborate more in the proposal.\n>\n\nYep!\n\n> > I felt that keeping it general might seem vague, but that's the nature\n> > of the project. Every variable\n> > is unique and would need a different approach and outlining the\n> > approach of each variable\n> > in the proposal is not very feasible, as these decisions need to\n> > happen collaboratively through\n> > discussions in the community.\n> >\n>\n> Yes, so you could firstly give how you want to handle the global\n> variables from top. And give some concrete examples to demonstrate your\n> idea.\n>\n\nAlright, will do.\n\nI'll send a new iteration of the proposal soon.\n\nThank you so much for your inputs:)\nAyush\n\nOn Mon, Mar 31, 2025 at 7:47 PM shejialuo <shejialuo@gmail.com> wrote:\n>\n> On Sat, Mar 29, 2025 at 03:24:05PM +0530, Ayush Chandekar wrote:\n>\n> [snip]\n>\n> > > > One key challenge is determining which variables should be part of\n> > > > `repo_settings` and which should remain separate. While working on the patch to\n> > > > refactor access to `core.attributesfile`, I received feedback from Junio that not\n> > > > all global variables should be blindly moved into the `repo_settings` struct.\n> > > > This reinforced the need to carefully assess which variables belong in `repo_settings`\n> > > > and which should be handled differently.\n> > > >\n> > >\n> > > Yes, this is correct. I somehow think whether we should put this\n> > > paragraph into Pre-GSoC part? I think that you have found this when\n> > > adding a patch to remove one global variable. And thus by communicating\n> > > with the community, you have further understood that the requirement and\n> > > the detail of this project.\n> >\n> > Yep, since I encountered this while working on the patch, it fits well\n> > in the Pre-GSoC section.\n> > Moving it there would better show how I learned more about the\n> > project's scope through\n> > community feedback.\n> >\n>\n> Yes, this is my intention. This represents your ability where you\n> interact with the community and get feedback. And this is what we want\n> to see.\n>\n> > >\n> > > And in your plan, you should just say that we need to do this. Would\n> > > this be better?\n> > >\n> > So, I should remove all the categorization stuff and just say that I\n> > would focus on\n> > each variable, discuss in the community whether it should belong in the struct\n> > repo_settings/repo or not while sending patches?\n>\n> I think you should put the categorization stuff into after-GSoC part.\n> Well, I don't think you could focus on _each_ variable. This is\n> impossible for you to talk about the way for _each_ variable. I somehow\n> think that you could just write the proposal about how to handle one or\n> two global variables.\n>\n> You already touch one setting \"core.attributesfile\" right? You may just\n> elaborate more in the proposal.\n>\n> > I felt that keeping it general might seem vague, but that's the nature\n> > of the project. Every variable\n> > is unique and would need a different approach and outlining the\n> > approach of each variable\n> > in the proposal is not very feasible, as these decisions need to\n> > happen collaboratively through\n> > discussions in the community.\n> >\n>\n> Yes, so you could firstly give how you want to handle the global\n> variables from top. And give some concrete examples to demonstrate your\n> idea.\n>\n> > Should I still mention that once the project is complete, we could\n> > consider structuring related\n> > stuff if the community sees value in it.\n> >\n>\n> You could, mention this in after GSoC part.\n>\n> > > > This plan is flexible and may be refined through multiple iterations as I receive\n> > > > feedback from the community and reviewers.\n> > > >\n> > > > Timeline:\n> > > > ---------\n> > > >\n> > > > Pre-GSOC:\n> > > > (Until 8 May)\n> > > > -     Explore the codebase more, focusing on environment-related code paths.\n> > > > -     Document how each global variable is used and how it can be moved to\n> > > >       repository settings.\n> > > > -     Study Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n> > > >\n> > > > ----------\n> > > >\n> > > > Community Bonding:\n> > > > (May 8 - June 1)\n> > > > -     Engage with mentors to discuss different environment variables, their\n> > > >       dependencies, and the best approach for refactoring.\n> > > > -     Finalize an implementation plan based on discussions.\n> > > > -     Since I will be on summer vacation, I can start coding early and make progress\n> > > >       on the project.\n> > > >\n> > > > ----------\n> > > >\n> > > > Coding Period:\n> > > > (June 2 - August 25)\n> > > > -     Refactor global variables, replacing them with repository-scoped\n> > > >       configurations.\n> > > > -     Modify function signatures to pass `struct repository` explicitly instead\n> > > >       of relying on `the_repository`.\n> > > > -     Categorize variables into specialized structs to improve modularity and\n> > > >       maintainability.\n> > >\n> > > As I have said, this is a high-risk task. Categorization needs many\n> > > iterations. And we may do this after GSoC.\n> >\n> > Yep, will update that.\n> >\n> > Thanks for your review, again:)\n> >\n> > Ayush\n>\n> Thanks,\n> Jialuo\n"},{"id":"515371","messageId":"CAE7as+ZiXQiTg-YSPxmXWB3X+=WSXPpK8fiSrqQhNCpWQpHTAA@mail.gmail.com","threadId":"63196","inReplyTo":"CAE7as+ZF6ARDQjGTyhjP7JZqhpbvZeouKGZA+tdZur_-8a5EXw@mail.gmail.com","subject":"Re: [GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-03-31T15:18:01Z","receivedAt":"2025-03-31T15:18:13Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Please excuse the top posting in my previous mail.\n"},{"id":"515641","messageId":"20250404085133.1098274-1-ayu.chandekar@gmail.com","threadId":"63196","inReplyTo":"20250326052602.265989-1-ayu.chandekar@gmail.com","subject":"[GSOC] [PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-04-04T08:51:31Z","receivedAt":"2025-04-04T08:51:57Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Hello,\nThis is my GSoC 2025 proposal for the project \"Refactoring in order to reduce Git’s global state\".\nYou can view docs version here: \nhttps://docs.google.com/document/d/1tJrtWxo1UGKChB3hu5eZ-ljm0FtU_fsv0TnIRwu3EKY/edit?usp=sharing\n\n---------\n\nRefactoring in order to reduce git’s state\n\nMy Information:\n---------------\n\nName: Ayush Chandekar\nEmail: ayu.chandekar@gmail.com\nMobile No: (+91) 9372496874\nEducation: UG Sophomore, IIT Roorkee\nGithub: https://github.com/ayu-ch\nBlog: https://ayu-ch.github.io\n\n\nAbout me:\n---------\n\nI'm Ayush Chandekar, a UG Sophomore studying at Indian Institute of\nTechnology, Roorkee. I like participating in various software development\nand tech-development endeavors, usually hackathons, CTFs, and projects at\nSDSLabs. SDSLabs is a student-run technical group that includes passionate\ndevelopers and designers interested in various fields and involved in multiple\nsoftware development projects that aim to foster a software development\nculture on campus. Being a part of this group has exposed me to different\nsoftware development methodologies, tools and frameworks and helped me become\ncomfortable contributing to an open-source project with multiple contributors.\nSome open-source contributions I made here are: [1], [2] & [3]\n\nI see this project as a meaningful opportunity to deepen my involvement in\nthe Git community and to build a foundation for continued contributions to\nopen source development in the future.\n\n\nOverview:\n---------\n\nGit currently uses a global object called `the_repository`, which refers to a\nsingle instance of `struct repository`. Many internal functions rely on this\nglobal object rather than accepting a `struct repository` as an explicit\nparameter. This design inherently assumes a single active repository,\nmaking it difficult to support multi-repository use cases and obstructing\nthe long-term goal of libification of Git.\n\nA key architectural limitation is that while `struct repository` encapsulates\nsome repository-specific information, many important environment variables\nand configuration settings that logically belong to a repository are still\nstored as global variables, primarily in `environment.c`, not within the\n`repository` struct. As a result, even if multiple repositories were to\nexist concurrently, they would still share this global state, leading to\nincorrect behavior, race conditions, or subtle bugs.\n\nThis project aims to refactor Git’s environment handling by relocating global\nvariables into more appropriate local contexts, primarily within \nstruct repository and struct repo_settings. However, some global variables may\nonly apply to specific subsystems. In such cases, rather than placing them in\nstruct repository or struct repo_settings, they should be moved into a\ncontext that better reflects their scope.\n\nThis change will not only make the environment state repository-specific but\nalso improve the modularity and maintainability of the codebase. The work\ninvolves identifying environment-related global variables, determining the\nmost suitable structure to house them, and updating all affected code paths\naccordingly.\n\nThe difficulty of this project is medium, and it is estimated to take \n175 to 350 hours.\n\n\nPre-GSOC:\n---------\n\nI started exploring Git’s codebase and documentation around the end of\nJanuary, familiarizing myself with its structure and development practices. I\nsubmitted a microproject, which helped me navigate the code and contribution\nworkflow.\n\nAfter selecting the project on refactoring Git’s state, I studied the\nsurrounding code and reviewed past patches ([4], [5], [6], [7], [8] & [9])\nto understand the reasoning behind previous changes. \n\nTo better prepare for the GSoC timeline, I submitted a patch related to the\nproject, to gain hands-on experience with both the implementation details\nand the submission process. The patch focused on refactoring access to\n`core.attributesfile`.\n\nThrough discussions and feedback from the community, I gained a clearer \nunderstanding of a key aspect of the project:\ndetermining whether certain variables should belong to repo_settings/\nrepository or be part of a separate subsystem.\n\nJunio pointed out in a feedback that not all global variables should\nbe blindly moved into `repo_settings`.\nSpecifically, for `git_attributes_file`, adding it to the repository struct\ndoesn’t make sense. He explained that it’s similar to how index_state is\nhandled, while index_state knows which repository it belongs to, the\nrepository struct only holds a pointer to a single index_state instance\nand isn’t aware of other instances.\n\nFollowing this approach, instead of placing `git_attributes_file` in the\nrepository struct, we can house it within an attribute set and pass a\npointer to that set wherever needed.\n\nThis practice patch gave me a clearer understanding of the project.\n\nPatches:\n--------\n\nFor git:\n\n+ (Microproject) t6423: fix suppression of Git’s exit code in tests\n\tThread:\n\thttps://public-inbox.org/git/20250202120926.322417-1-ayu.chandekar@gmail.com/\n\tStatus: Merged into master \n\tCommit Hash: 7c1d34fe5d1229362f2c3ecf2d493167a1f555a2 \n\tDescription: Instead of executing a Git command as the upstream component of\n\t\t\t\t a pipe, which can result in the exit status being lost, redirect\n\t\t\t\t its output to a file and then process that file in two steps to\n\t\t\t\t ensure the exit status is properly preserved.\n\n+ midx: implement progress reporting for QSORT operation\n\tThread:\n\thttps://public-inbox.org/git/20250210074623.136599-1-ayu.chandekar@gmail.com/\n\tStatus: Dropped \n\tDescription: Add progress reporting during the QSORT operation in \n\t\t\t\t multi-pack-index verification. While going through the code, \n\t\t\t\t I found this TODO, which I thought was interesting however my \n\t\t\t\t approach assumed that the qsort() operation processes elements\n\t\t\t\t in a structured order, which isn't guaranteed.\n\n+ Stop depending on `the_repository` for core.attributesfile\n\tThread:\n\thttps://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@gmail.com/\n\tStatus: WIP, needs more discussion.  \n\tDescription: This patch refactors access to the `core.attributesfiles` \n\t\t\t\t configuration by moving it into the `repo_settings` struct.\n\t\t\t\t It eliminates the global variable `git_attributes_file` and \n\t\t\t\t updates relevant code paths to pass the `struct repository`\n\t\t\t\t as a parameter.\n\nFor git.github.io:\n\n+ GSoC-participants: add GSoC 2024 participants to the list #762\n\tStatus: Merged into master\n\tDescription: Adding GSoC 2024 participants will help new\n\t\t\t\t contributors understand their journey, making it easier for them \n\t\t\t\t to navigate the program and the project.\n\nProposed Plan:\n--------------\n\nI have been reviewing global variables across the codebase to understand their\ndependencies and impact. To do this, I examined `config.c` and cross-referenced\nit with `environment.c` to see how these variables are currently managed. The\ngoal of this project is to eliminate global variables by moving their\nconfigurations into their local contexts. \n\nThe general approach for handling a global variable begins with understanding\nits purpose. This involves tracing its usage across the codebase and identifying\nthe subsystem it should belong to. If the variable is closely tied to\nrepository-related functionality, it may belong in struct repository or\nstruct repo_settings. Otherwise, it should be placed in a more suitable\ncontext based on its scope.\n\nAdditionally, it's important to review previous attempts or related patches\nto understand past design decisions and ensure consistency with ongoing efforts.\nFinally, the global instance is eliminated by relocating the variable into the\nappropriate context and passing it through the relevant code paths.\n\nExample: Handling `is_bare_repository_cfg`\nThe variable `is_bare_repository_cfg` determines whether a repository is bare,\nmeaning it lacks a working directory. Since this property is fundamental to\nhow a repository functions, it should be placed in struct repository.\n\nI have also gone through the code paths and analyzed how this variable is\ninitialized. We can initialize it similarly to how hash_algo is set through\nthe repository format. The repository format already contains an `is_bare`\nfield, which we can use to set this variable inside struct repository.\n\nHowever, I still have some questions regarding why the is_bare_repository()\nfunction checks for `repo->worktree` and why the `worktree struct` itself has\nan `is_bare` variable. If a repository is considered bare when !repo->worktree\nis true, the role of `worktree->is_bare` needs further clarification. I believe\nthat by engaging with the community, my understanding will become clearer.\nI also went through [4] to see how John Cai's approach was. \n\nThis is how we can also approach for other global variables.\nThrough multiple iterations, this approach will be refined based on feedback, \nedge cases, and community input.\n\n\nTimeline:\n---------\n\nPre-GSOC: \n(Until 8 May) \n-\tExplore the codebase more, focusing on environment-related code paths.\n-\tDocument how each global variable is used and how it can be moved to \n\trepository settings.  \n-\tStudy Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n\n----------\n\nCommunity Bonding: \n(May 8 - June 1) \n-\tEngage with mentors to discuss different environment variables, their \n\tdependencies, and the best approach for refactoring.\n-\tFinalize an implementation plan based on discussions.\n-\tSince I will be on summer vacation, I can start coding early and make progress \n\ton the project.\n\n----------\n\nCoding Period: \n(June 2 - August 25) \n-\tIdentify the appropriate subsystem for each global variable and relocate it \n\tinto struct repository, struct repo_settings, or other suitable contexts.\n-\tModify function signatures to pass the new contexts explicitly, replacing \n\treliance on global variables.\n-\tContinuously submit patches for review and incorporate feedback from mentors\n\tand the community.  \n-\tI plan to write weekly blogs which will document what I did in the whole \n\tweek.\n\n----------\n\nFinal Week: \n(August 25 - September 1) \n-\tWrite a detailed report on the entire project.  \n-\tFix bugs if any.  \n-\tReflect on the project, noting challenges faced and lessons learned.\n\n\nBlogging:\n---------\n\nI have also set up a blogging page at [10]. While reading blogs from previous\nGSoC contributors, I found them useful in understanding the challenges\nthey faced and how they approached their projects. Their experiences gave\nme a better idea of what to expect and how to navigate the development\nprocess. Inspired by this, I decided to start my own blog to document my\njourney throughout GSoC. This will not only help me track my own progress but\nalso serve as a resource for future contributors who might work on similar\nprojects. I plan to share updates on my work, challenges encountered and\ninsights gained from discussions with mentors and the community.\n\nAdditionally, I hope my blog encourages more people to contribute to open\nsource by providing a transparent look into the development process. Writing\nabout my experience will also help me reflect on my work and improve my\nability to communicate technical ideas effectively.\n\nI liked the format and structure of Chandra's blog, so I decided to use the\nsame template for my own blogging page.\n\n\nAvailability:\n-------------\n\nAs a college student, I intend to utilise my summer breaks from May to July\nto work on the project. After completing my University exams in April, I can\nstart working in May. I can dedicate 40 hours a week from May to July, while\nin August after the classes commence, I can dedicate about 25 hours a week.\n\nThere are no exams or planned vacations throughout the coding period. Besides\nthis project, I have no commitments/vacations planned for the summer. I shall\nkeep my status posted to all the community members and maintain transparency\nin the project.\n\n\nPost-GSOC:\n----------\n\nBeyond contributing code, I strongly believe in giving back to the community\nand helping others grow. Open source thrives on mentorship, knowledge sharing,\nand long-term involvement, and I would love to continue contributing even\nafter GSoC ends.\n\nI have always valued mentorship, both as a mentee and as someone who enjoys\nguiding others. If given the opportunity, I would be more than happy to\nmentor/co-mentor future GSoC contributors. By staying involved in the\ncommunity, whether through contributing, reviewing patches, or mentoring,\nI hope to help sustain and expand the project’s reach. I look at GSoC as not \njust as a one-time contribution but as a step toward a longer-term relationship\nwith open source.\n\nI will continue to be involved with Git even after GSoC by contributing patches,\nreviewing code, and participating in discussions. My work on refactoring Git’s \nstate aligns with long-term improvements to the codebase, and I plan to keep \nrefining it beyond the program. I see GSoC as just the beginning of my journey\nwith Git.\n\nAppreciation:\n-------------\n\nI appreciate the Git community for its excellent documentation, which made it \nmuch easier for me to understand Git in depth. The well-structured resources \nhelped me navigate the codebase and gain a deeper understanding of how Git \nworks internally.\n\nBeyond the documentation, I am also grateful for how welcoming and supportive \nthe community has been. Whether through discussions on the mailing list or \nfeedback on my patches, the information and guidance I received made my \nexperience even better.\n\nAdditionally, I read the blogs and proposals of Chandra, Jialuo, and Ghanashyam, \nwhich provided valuable insights into their journeys and helped me shape my \nown approach to contributing.\n\nThanks for reviewing this proposal.\n\nReferences:\n-----------\n\n[1] https://github.com/sdslabs/beast/pull/374\n\n[2] https://github.com/sdslabs/beast/tree/add-teams-with-hint\n\n[3] https://github.com/sdslabs/playCTF/pull/177\n\n[4] https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n\n[5] https://public-inbox.org/git/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/\n\n[6] https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/\n\n[7] https://public-inbox.org/git/pull.1829.git.1731653548549.gitgitgadget@gmail.com/#t\n\n[8] https://public-inbox.org/git/cover.1733236936.git.karthik.188@gmail.com/\n\n[9] https://public-inbox.org/git/cover.1724923648.git.ps@pks.im/\n\n[10] https://ayu-ch.github.io\n"},{"id":"515671","messageId":"CAOLa=ZQ8KvAZjsDWerF0E9VUzsbNOj+Vcxo_mFL5Y3Of9iCAHQ@mail.gmail.com","threadId":"63196","inReplyTo":"20250404085133.1098274-1-ayu.chandekar@gmail.com","subject":"Re: [GSOC] [PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-04-04T14:45:52Z","receivedAt":"2025-04-04T14:45:54Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Ayush Chandekar <ayu.chandekar@gmail.com> writes:\n\n[snip]\n\n> Proposed Plan:\n> --------------\n>\n> I have been reviewing global variables across the codebase to understand their\n> dependencies and impact. To do this, I examined `config.c` and cross-referenced\n> it with `environment.c` to see how these variables are currently managed. The\n> goal of this project is to eliminate global variables by moving their\n> configurations into their local contexts.\n>\n> The general approach for handling a global variable begins with understanding\n> its purpose. This involves tracing its usage across the codebase and identifying\n> the subsystem it should belong to. If the variable is closely tied to\n> repository-related functionality, it may belong in struct repository or\n> struct repo_settings. Otherwise, it should be placed in a more suitable\n> context based on its scope.\n>\n> Additionally, it's important to review previous attempts or related patches\n> to understand past design decisions and ensure consistency with ongoing efforts.\n> Finally, the global instance is eliminated by relocating the variable into the\n> appropriate context and passing it through the relevant code paths.\n>\n> Example: Handling `is_bare_repository_cfg`\n> The variable `is_bare_repository_cfg` determines whether a repository is bare,\n> meaning it lacks a working directory. Since this property is fundamental to\n> how a repository functions, it should be placed in struct repository.\n>\n> I have also gone through the code paths and analyzed how this variable is\n> initialized. We can initialize it similarly to how hash_algo is set through\n> the repository format. The repository format already contains an `is_bare`\n> field, which we can use to set this variable inside struct repository.\n>\n> However, I still have some questions regarding why the is_bare_repository()\n> function checks for `repo->worktree` and why the `worktree struct` itself has\n> an `is_bare` variable. If a repository is considered bare when !repo->worktree\n> is true, the role of `worktree->is_bare` needs further clarification. I believe\n> that by engaging with the community, my understanding will become clearer.\n> I also went through [4] to see how John Cai's approach was.\n>\n> This is how we can also approach for other global variables.\n> Through multiple iterations, this approach will be refined based on feedback,\n> edge cases, and community input.\n>\n\nSo the approach you suggest is to comb through the global variables and\nconfig and find new locations for them to be stored. While this is\ndefinitely a bunch chunk of the problem, shouldn't we also talk about\nhow we can reduce usage of some of these variables?\n\nIn particular, I'm wondering how you'd want to tackle 'the_repository'\nusage. There is some previous work done here, where Patrick added the\n'#define USE_THE_REPOSITORY_VARIABLE' definition which tracks usage of\nglobal variable and usage of them in different files.\n\nA possible approach which has been followed is to simply go from the\nbottom layers of the code upwards, cleaning up usage of global variables\nand ensuring we can remove '#define USE_THE_REPOSITORY_VARIABLE' from\nfiles. This is also the approach taken in some of the patches that\nyou've linked.\n\n[snip]\n"},{"id":"515717","messageId":"CAE7as+atJcycd4Awav6RKkTDvwiocyv4j=0rZvEhDcVpREsmqA@mail.gmail.com","threadId":"63196","inReplyTo":"CAOLa=ZQ8KvAZjsDWerF0E9VUzsbNOj+Vcxo_mFL5Y3Of9iCAHQ@mail.gmail.com","subject":"Re: [GSOC] [PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-04-06T10:44:34Z","receivedAt":"2025-04-06T10:44:45Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":">\n> So the approach you suggest is to comb through the global variables and\n> config and find new locations for them to be stored. While this is\n> definitely a bunch chunk of the problem, shouldn't we also talk about\n> how we can reduce usage of some of these variables?\n>\n> In particular, I'm wondering how you'd want to tackle 'the_repository'\n> usage. There is some previous work done here, where Patrick added the\n> '#define USE_THE_REPOSITORY_VARIABLE' definition which tracks usage of\n> global variable and usage of them in different files.\n>\n> A possible approach which has been followed is to simply go from the\n> bottom layers of the code upwards, cleaning up usage of global variables\n> and ensuring we can remove '#define USE_THE_REPOSITORY_VARIABLE' from\n> files. This is also the approach taken in some of the patches that\n> you've linked.\n>\n\nYour approach makes a lot of sense to me, that is, picking a specific\nsubsystem or file and aiming to remove the `#define USE_THE_REPOSITORY_VARIABLE`\ndefinition and thus 'the_repository' eventually. This was the method\nused by Patrick to tackle\nthe object subsystem in [1]  and the path subsystem in [2] and you to\ntackle the packfile in [3].\nThis approach also helps in removing some of the global variables used\nwithin that particular\nsubsystem, which is a nice bonus.\n\nHowever, this approach might not be feasible for the global variables that\narent tightly tied to a single subsystem. So what I can do is, for removing\n`the_repository`, I can follow the approach you mentioned, and for relocating\nthe more general global variables, I can use the approach which I\ntalked about in the\nproposal.\n\nWhat do you think?\n\n[1]: https://public-inbox.org/git/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/\n[2]: https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/\n[3]: https://public-inbox.org/git/cover.1733236936.git.karthik.188@gmail.com/\n"},{"id":"515747","messageId":"CAE7as+bmkHgrNtqkw76myE7WVen2S5URToXzVqgnRzOWj_-fhg@mail.gmail.com","threadId":"63196","inReplyTo":"20250404085133.1098274-1-ayu.chandekar@gmail.com","subject":"Re: [GSOC] [PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-04-07T08:42:24Z","receivedAt":"2025-04-07T08:42:36Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Hey Patrick,\n\nIt would be great if you could take a look at my proposal, especially since\nyou've worked on this area before. Any feedback would be really appreciated!\n\nThanks!\nAyush\n"},{"id":"515749","messageId":"CAP8UFD0a9rvVEJj4nk0ONK7=HXYRS1td6nEw7nO6mhj4gTjY9g@mail.gmail.com","threadId":"63196","inReplyTo":"CAE7as+atJcycd4Awav6RKkTDvwiocyv4j=0rZvEhDcVpREsmqA@mail.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":"2025-04-07T09:06:18Z","receivedAt":"2025-04-07T09:06:32Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Apr 6, 2025 at 12:44 PM Ayush Chandekar <ayu.chandekar@gmail.com> wrote:\n>\n> >\n> > So the approach you suggest is to comb through the global variables and\n> > config and find new locations for them to be stored. While this is\n> > definitely a bunch chunk of the problem, shouldn't we also talk about\n> > how we can reduce usage of some of these variables?\n> >\n> > In particular, I'm wondering how you'd want to tackle 'the_repository'\n> > usage. There is some previous work done here, where Patrick added the\n> > '#define USE_THE_REPOSITORY_VARIABLE' definition which tracks usage of\n> > global variable and usage of them in different files.\n> >\n> > A possible approach which has been followed is to simply go from the\n> > bottom layers of the code upwards, cleaning up usage of global variables\n> > and ensuring we can remove '#define USE_THE_REPOSITORY_VARIABLE' from\n> > files. This is also the approach taken in some of the patches that\n> > you've linked.\n> >\n>\n> Your approach makes a lot of sense to me, that is, picking a specific\n> subsystem or file and aiming to remove the `#define USE_THE_REPOSITORY_VARIABLE`\n> definition and thus 'the_repository' eventually. This was the method\n> used by Patrick to tackle\n> the object subsystem in [1]  and the path subsystem in [2] and you to\n> tackle the packfile in [3].\n> This approach also helps in removing some of the global variables used\n> within that particular\n> subsystem, which is a nice bonus.\n>\n> However, this approach might not be feasible for the global variables that\n> arent tightly tied to a single subsystem.\n\nWell, initially 'the_repository' wasn't tightly tied to a single\nsubsystem and even now I am not sure we could say it's tightly tied to\na single subsystem. Or maybe I don't understand what you mean.\n\nDo you mean that it's tightly tied because it needs `#define\nUSE_THE_REPOSITORY_VARIABLE`?\n\nBut for other global variables it could be possible to define and use\nsimilar macros. This way it might be possible to remove those\nvariables step by step only in some files.\n\n> So what I can do is, for removing\n> `the_repository`, I can follow the approach you mentioned, and for relocating\n> the more general global variables, I can use the approach which I\n> talked about in the\n> proposal.\n>\n> What do you think?\n\nIf removing `the_repository` is part of your proposal, then yeah,\ndescribing the approach you will use to remove is a good idea.\n"},{"id":"515750","messageId":"CAE7as+bnsBMW=UQtzQrNKTK3cMDSyYP=Q1EqEb2z8-ur3_my5w@mail.gmail.com","threadId":"63196","inReplyTo":"CAP8UFD0a9rvVEJj4nk0ONK7=HXYRS1td6nEw7nO6mhj4gTjY9g@mail.gmail.com","subject":"Re: [GSOC] [PROPOSAL v2]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-04-07T10:07:38Z","receivedAt":"2025-04-07T10:07:50Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":">\n> Well, initially 'the_repository' wasn't tightly tied to a single\n> subsystem and even now I am not sure we could say it's tightly tied to\n> a single subsystem. Or maybe I don't understand what you mean.\n>\n> Do you mean that it's tightly tied because it needs `#define\n> USE_THE_REPOSITORY_VARIABLE`?\n>\nSorry if I was not clear earlier. I wasn't referring to\n'the_repository' being tied, it was about other\nglobal variables being tied to a subsystem.\nWhat I meant is that the approach of picking a subsystem and removing the\n`#define USE_THE_REPOSITORY_VARIABLE` is really effective for removing\n'the_repository.'\nIt also helps in localizing the global variables from environment.h\nthat are specific to that subsystem,\neither into the subsystem itself or into struct repository / repo_settings.\n\nBut let's say if a global variable is common to 2-3 different subsystems, then\nthis approach would not be feasible for that variable. For that, I\nwould require to individually\ntackle that variable. This is an approach which I mentioned in my proposal.\n\nSo using these two approaches according to different needs, I can move forward.\n\n> But for other global variables it could be possible to define and use\n> similar macros. This way it might be possible to remove those\n> variables step by step only in some files.\n>\nYes, I still need to think through how that would align with the\napproach I mentioned.\nDefining a single macro like `#define USE_GLOBAL_VARIABLES` is\nsomething I can look into.\n\n> > So what I can do is, for removing\n> > `the_repository`, I can follow the approach you mentioned, and for relocating\n> > the more general global variables, I can use the approach which I\n> > talked about in the\n> > proposal.\n> >\n> > What do you think?\n>\n> If removing `the_repository` is part of your proposal, then yeah,\n> describing the approach you will use to remove is a good idea.\n\nYes, it is a part of the project but I haven't added this specific\napproach in the proposal yet and was hence asking if I can.\nThanks:)\n"},{"id":"515863","messageId":"20250408125220.59963-1-ayu.chandekar@gmail.com","threadId":"63196","inReplyTo":"20250326052602.265989-1-ayu.chandekar@gmail.com","subject":"[GSOC] [PROPOSAL v3]: Refactoring in order to reduce Git’s global state","fromName":"Ayush Chandekar","fromEmail":"ayu.chandekar@gmail.com","sentAt":"2025-04-08T12:52:19Z","receivedAt":"2025-04-08T12:52:39Z","isPatch":false,"sender":{"key":"ayu.chandekar@gmail.com","avatar":"https://avatars.githubusercontent.com/u/137001939?v=4"},"body":"Hello,\nThis is the third version of my GSoC 2025 proposal for the project \n\"Refactoring in order to reduce Git’s global state\".\n\nThe key change from v2 to this v3 is that I’ve added how I plan to tackle \nthe 'the_repository' global object.\n\nYou can view docs version here: \nhttps://docs.google.com/document/d/1tJrtWxo1UGKChB3hu5eZ-ljm0FtU_fsv0TnIRwu3EKY/edit?usp=sharing\n\n---------\n\nRefactoring in order to reduce git’s state\n\nMy Information:\n---------------\n\nName: Ayush Chandekar\nEmail: ayu.chandekar@gmail.com\nMobile No: (+91) 9372496874\nEducation: UG Sophomore, IIT Roorkee\nGithub: https://github.com/ayu-ch\nBlog: https://ayu-ch.github.io\n\n\nAbout me:\n---------\n\nI'm Ayush Chandekar, a UG Sophomore studying at Indian Institute of\nTechnology, Roorkee. I like participating in various software development\nand tech-development endeavors, usually hackathons, CTFs, and projects at\nSDSLabs. SDSLabs is a student-run technical group that includes passionate\ndevelopers and designers interested in various fields and involved in multiple\nsoftware development projects that aim to foster a software development\nculture on campus. Being a part of this group has exposed me to different\nsoftware development methodologies, tools and frameworks and helped me become\ncomfortable contributing to an open-source project with multiple contributors.\nSome open-source contributions I made here are: [1], [2] & [3]\n\nI see this project as a meaningful opportunity to deepen my involvement in\nthe Git community and to build a foundation for continued contributions to\nopen source development in the future.\n\n\nOverview:\n---------\n\nGit currently uses a global object called `the_repository`, which refers to a\nsingle instance of `struct repository`. Many internal functions rely on this\nglobal object rather than accepting a `struct repository` as an explicit\nparameter. This design inherently assumes a single active repository,\nmaking it difficult to support multi-repository use cases and obstructing\nthe long-term goal of libification of Git.\n\nA key architectural limitation is that while `struct repository` encapsulates\nsome repository-specific information, many important environment variables\nand configuration settings that logically belong to a repository are still\nstored as global variables, primarily in `environment.c`, not within the\n`repository` struct. As a result, even if multiple repositories were to\nexist concurrently, they would still share this global state, leading to\nincorrect behavior, race conditions, or subtle bugs.\n\nThis project aims to refactor Git’s environment handling by relocating global\nvariables into more appropriate local contexts, primarily within \nstruct repository and struct repo_settings. However, some global variables may\nonly apply to specific subsystems. In such cases, rather than placing them in\nstruct repository or struct repo_settings, they should be moved into a\ncontext that better reflects their scope.\n\nThis change will not only make the environment state repository-specific but\nalso improve the modularity and maintainability of the codebase. The work\ninvolves identifying environment-related global variables, determining the\nmost suitable structure to house them, and updating all affected code paths\naccordingly.\n\nThe difficulty of this project is medium, and it is estimated to take \n175 to 350 hours.\n\n\nPre-GSOC:\n---------\n\nI started exploring Git’s codebase and documentation around the end of\nJanuary, familiarizing myself with its structure and development practices. I\nsubmitted a microproject, which helped me navigate the code and contribution\nworkflow.\n\nAfter selecting the project on refactoring Git’s state, I studied the\nsurrounding code and reviewed past patches ([4], [5], [6], [7], [8] & [9])\nto understand the reasoning behind previous changes. \n\nTo better prepare for the GSoC timeline, I submitted a patch related to the\nproject, to gain hands-on experience with both the implementation details\nand the submission process. The patch focused on refactoring access to\n`core.attributesfile`.\n\nThrough discussions and feedback from the community, I gained a clearer \nunderstanding of a key aspect of the project:\ndetermining whether certain variables should belong to repo_settings/\nrepository or be part of a separate subsystem.\n\nJunio pointed out in a feedback that not all global variables should\nbe blindly moved into `repo_settings`.\nSpecifically, for `git_attributes_file`, adding it to the repository struct\ndoesn’t make sense. He explained that it’s similar to how index_state is\nhandled, while index_state knows which repository it belongs to, the\nrepository struct only holds a pointer to a single index_state instance\nand isn’t aware of other instances.\n\nFollowing this approach, instead of placing `git_attributes_file` in the\nrepository struct, we can house it within an attribute set and pass a\npointer to that set wherever needed.\n\nThis practice patch gave me a clearer understanding of the project.\n\nPatches:\n--------\n\nFor git:\n\n+ (Microproject) t6423: fix suppression of Git’s exit code in tests\n\tThread:\n\thttps://public-inbox.org/git/20250202120926.322417-1-ayu.chandekar@gmail.com/\n\tStatus: Merged into master \n\tCommit Hash: 7c1d34fe5d1229362f2c3ecf2d493167a1f555a2 \n\tDescription: Instead of executing a Git command as the upstream component of\n\t\t\t\t a pipe, which can result in the exit status being lost, redirect\n\t\t\t\t its output to a file and then process that file in two steps to\n\t\t\t\t ensure the exit status is properly preserved.\n\n+ midx: implement progress reporting for QSORT operation\n\tThread:\n\thttps://public-inbox.org/git/20250210074623.136599-1-ayu.chandekar@gmail.com/\n\tStatus: Dropped \n\tDescription: Add progress reporting during the QSORT operation in \n\t\t\t\t multi-pack-index verification. While going through the code, \n\t\t\t\t I found this TODO, which I thought was interesting however my \n\t\t\t\t approach assumed that the qsort() operation processes elements\n\t\t\t\t in a structured order, which isn't guaranteed.\n\n+ Stop depending on `the_repository` for core.attributesfile\n\tThread:\n\thttps://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@gmail.com/\n\tStatus: WIP, needs more discussion.  \n\tDescription: This patch refactors access to the `core.attributesfiles` \n\t\t\t\t configuration by moving it into the `repo_settings` struct.\n\t\t\t\t It eliminates the global variable `git_attributes_file` and \n\t\t\t\t updates relevant code paths to pass the `struct repository`\n\t\t\t\t as a parameter.\n\nFor git.github.io:\n\n+ GSoC-participants: add GSoC 2024 participants to the list #762\n\tStatus: Merged into master\n\tDescription: Adding GSoC 2024 participants will help new\n\t\t\t\t contributors understand their journey, making it easier for them \n\t\t\t\t to navigate the program and the project.\n\n+ Rename references from *.txt to *.adoc in documentation paths. #769\n\tStatus: Merged into master\n\tDescription: Since the documentation in git is changed from *.txt to *.adoc\n\t\t\t\t format. Update references to reflect that change.\n\n+ Rename references from *.txt to *.adoc in Rev News editions. #770\n\tStatus: Merged into master\n\tDescription: Since the documentation in git is changed from *.txt to *.adoc\n\t\t\t\t format. Update references in previous editions to reflect that change.\n\nProposed Plan:\n--------------\n\nI have been reviewing global variables across the codebase to understand their\ndependencies and impact. To do this, I examined `config.c` and cross-referenced\nit with `environment.c` to see how these variables are currently managed. The\ngoal of this project is to eliminate global variables by moving their\nconfigurations into their local contexts. \n\nThe general approach for handling a global variable begins with understanding\nits purpose. This involves tracing its usage across the codebase and identifying\nthe subsystem it should belong to. If the variable is closely tied to\nrepository-related functionality, it may belong in struct repository or\nstruct repo_settings. Otherwise, it should be placed in a more suitable\ncontext based on its scope.\n\nAdditionally, it's important to review previous attempts or related patches\nto understand past design decisions and ensure consistency with ongoing efforts.\nFinally, the global instance is eliminated by relocating the variable into the\nappropriate context and passing it through the relevant code paths.\n\nExample: Handling `is_bare_repository_cfg`\nThe variable `is_bare_repository_cfg` determines whether a repository is bare,\nmeaning it lacks a working directory. Since this property is fundamental to\nhow a repository functions, it should be placed in struct repository.\n\nI have also gone through the code paths and analyzed how this variable is\ninitialized. We can initialize it similarly to how hash_algo is set through\nthe repository format. The repository format already contains an `is_bare`\nfield, which we can use to set this variable inside struct repository.\n\nHowever, I still have some questions regarding why the is_bare_repository()\nfunction checks for `repo->worktree` and why the `worktree struct` itself has\nan `is_bare` variable. If a repository is considered bare when !repo->worktree\nis true, the role of `worktree->is_bare` needs further clarification. I believe\nthat by engaging with the community, my understanding will become clearer.\nI also went through [4] to see how John Cai's approach was. \n\nThis is how we can also approach for other global variables.\nThrough multiple iterations, this approach will be refined based on feedback, \nedge cases, and community input.\n\nOther than that, we have a global object 'the_repository'. As an attempt to  \nremove this globally, Patrick introduced a macro  \n`#define USE_THE_REPOSITORY_VARIABLE` in this patch: [10]. An approach I can  \nfollow is picking a subsystem or file, and aiming to remove the macro and  \nhence eliminating the usage of 'the_repository' in that subsystem/file by \npassing the `struct repository` explicitly through the call chain. \nThis approach also helps in removing some of the global variables in that  \nparticular subsystem. \nThis is also followed in the patches by Patrick in  \n[5] and [6] to tackle the object and path subsystem respectively and Karthik  \nin [8] to tackle the packfile subsystem.\n\n\nTimeline:\n---------\n\nPre-GSOC: \n(Until 8 May) \n-\tExplore the codebase more, focusing on environment-related code paths.\n-\tDocument how each global variable is used and how it can be moved to \n\trepository settings.  \n-\tStudy Git’s Coding Guidelines and the Pro Git Book to align with best practices.\n\n----------\n\nCommunity Bonding: \n(May 8 - June 1) \n-\tEngage with mentors to discuss different environment variables, their \n\tdependencies, and the best approach for refactoring.\n-\tFinalize an implementation plan based on discussions.\n-\tSince I will be on summer vacation, I can start coding early and make progress \n\ton the project.\n\n----------\n\nCoding Period: \n(June 2 - August 25) \n-\tIdentify the appropriate subsystem for each global variable and relocate it \n\tinto struct repository, struct repo_settings, or other suitable contexts.\n-\tModify function signatures to pass the new contexts explicitly, replacing \n\treliance on global variables.\n-\tPick subsystems and remove the macro \n\t#define USE_THE_REPOSITORY_VARIABLE and thereby eliminating usage\n\tof the global variable ‘the_repository’.\n-\tContinuously submit patches for review and incorporate feedback from mentors\n\tand the community.  \n-\tI plan to write weekly blogs which will document what I did in the whole \n\tweek.\n\n----------\n\nFinal Week: \n(August 25 - September 1) \n-\tWrite a detailed report on the entire project.  \n-\tFix bugs if any.  \n-\tReflect on the project, noting challenges faced and lessons learned.\n\n\nBlogging:\n---------\n\nI have also set up a blogging page at [11]. While reading blogs from previous\nGSoC contributors, I found them useful in understanding the challenges\nthey faced and how they approached their projects. Their experiences gave\nme a better idea of what to expect and how to navigate the development\nprocess. Inspired by this, I decided to start my own blog to document my\njourney throughout GSoC. This will not only help me track my own progress but\nalso serve as a resource for future contributors who might work on similar\nprojects. I plan to share updates on my work, challenges encountered and\ninsights gained from discussions with mentors and the community.\n\nAdditionally, I hope my blog encourages more people to contribute to open\nsource by providing a transparent look into the development process. Writing\nabout my experience will also help me reflect on my work and improve my\nability to communicate technical ideas effectively.\n\nI liked the format and structure of Chandra's blog, so I decided to use the\nsame template for my own blogging page.\n\n\nAvailability:\n-------------\n\nAs a college student, I intend to utilise my summer breaks from May to July\nto work on the project. After completing my University exams in April, I can\nstart working in May. I can dedicate 40 hours a week from May to July, while\nin August after the classes commence, I can dedicate about 25 hours a week.\n\nThere are no exams or planned vacations throughout the coding period. Besides\nthis project, I have no commitments/vacations planned for the summer. I shall\nkeep my status posted to all the community members and maintain transparency\nin the project.\n\n\nPost-GSOC:\n----------\n\nBeyond contributing code, I strongly believe in giving back to the community\nand helping others grow. Open source thrives on mentorship, knowledge sharing,\nand long-term involvement, and I would love to continue contributing even\nafter GSoC ends.\n\nI have always valued mentorship, both as a mentee and as someone who enjoys\nguiding others. If given the opportunity, I would be more than happy to\nmentor/co-mentor future GSoC contributors. By staying involved in the\ncommunity, whether through contributing, reviewing patches, or mentoring,\nI hope to help sustain and expand the project’s reach. I look at GSoC as not \njust as a one-time contribution but as a step toward a longer-term relationship\nwith open source.\n\nI will continue to be involved with Git even after GSoC by contributing patches,\nreviewing code, and participating in discussions. My work on refactoring Git’s \nstate aligns with long-term improvements to the codebase, and I plan to keep \nrefining it beyond the program. I see GSoC as just the beginning of my journey\nwith Git.\n\nAppreciation:\n-------------\n\nI appreciate the Git community for its excellent documentation, which made it \nmuch easier for me to understand Git in depth. The well-structured resources \nhelped me navigate the codebase and gain a deeper understanding of how Git \nworks internally.\n\nBeyond the documentation, I am also grateful for how welcoming and supportive \nthe community has been. Whether through discussions on the mailing list or \nfeedback on my patches, the information and guidance I received made my \nexperience even better.\n\nAdditionally, I read the blogs and proposals of Chandra, Jialuo, and Ghanashyam, \nwhich provided valuable insights into their journeys and helped me shape my \nown approach to contributing.\n\nThanks for reviewing this proposal.\n\nReferences:\n-----------\n\n[1] https://github.com/sdslabs/beast/pull/374\n\n[2] https://github.com/sdslabs/beast/tree/add-teams-with-hint\n\n[3] https://github.com/sdslabs/playCTF/pull/177\n\n[4] https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n\n[5] https://public-inbox.org/git/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/\n\n[6] https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/\n\n[7] https://public-inbox.org/git/pull.1829.git.1731653548549.gitgitgadget@gmail.com/#t\n\n[8] https://public-inbox.org/git/cover.1733236936.git.karthik.188@gmail.com/\n\n[9] https://public-inbox.org/git/cover.1724923648.git.ps@pks.im/\n\n[10] https://public-inbox.org/git/cover.1718347699.git.ps@pks.im/\n\n[11] https://ayu-ch.github.io\n"}]}