{"thread":{"id":"63259","subject":"[GSoC] [RFC] Project Proposal: Refactoring in order to reduce Git's global state","startedAt":"2025-04-05T10:41:32Z","lastAt":"2025-04-07T17:10:31Z","messageCount":3,"participants":["Anthony Wang","Kaartic Sivaraam"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"515694","messageId":"20250405104124.25272-1-anthonywang03@icloud.com","threadId":"63259","inReplyTo":null,"subject":"[GSoC] [RFC] Project Proposal: Refactoring in order to reduce Git's global state","fromName":"Anthony Wang","fromEmail":"anthonywang513@gmail.com","sentAt":"2025-04-05T10:41:24Z","receivedAt":"2025-04-05T10:41:32Z","isPatch":false,"sender":{"key":"anthonywang513@gmail.com","avatar":"https://avatars.githubusercontent.com/u/71832477?v=4"},"body":"From: Anthony Wang <anthonywang513@gmail.com>\n\nHi all,\n\nI'm interested in working with Git over the summer to \"Refactor in Order \nto Reduce Git's Global State.\" My main motivation for choosing this idea \nis that improving Git's environment handling will enhance long-term \nmaintainability and scalability, and allow for multiple-repository \ninteractions. \n\nThis is the first version of my proposal. I would love to \nreceive feedback on the content or structure, especially on the points \npertaining to the actual implementation of the project and planned work. \nI will also discuss my past experience, and speak on why I believe I \nwill be able to effectively contribute in a sustainable way to this \nlarge undertaking.\nThanks!\n\n-------------------------------------\n\n# Refactoring in Order to Reduce Git’s Global State\n\n### Personal Info\nName: Anthony Wang\nTimezone: Eastern Time (ET)/UTC -5\nGitHub: https://github.com/wang-anthony03\nLinkedIn: https://www.linkedin.com/in/anthonywang03/\n\n## About Me\n\nMy name is Anthony Wang, and I am a 3rd year Computer Science student \nat the University of Virginia. I have experience in software engineering \nand development, particularly in C, Python, and shell scripting. This is \nmy first time working with open source software, and I am incredibly \nexcited to contribute to Git, as I have always wanted to work on \ndeveloping the tools that I use everyday.\n\nMy background includes building scalable automation tools and \ncontributing to infrastructure projects at Verizon. I was able to work \nwith large codebases, and I learned the importance of clean, \nwell-documented code, as well as the challenges of tech-debt leading to \ndifficulties in maintaining code.\n\n## Previous Experience\n\n- Experience using Git extensively in academic and personal projects.\n- Experience working with C as the main language for multiple Computer \nSystems courses.\n- Developed a text editor in C: https://github.com/wang-anthony03/Quill\n\n## Project Proposal\n\n### Objective\nThis project aims to modernize Git's environment handling by refactoring \nthe environment.c code to reduce the reliance on global state. The goal \nis to move environment variables and configuration settings from the \nglobal scope into appropriate local contexts, primarily within struct \nrepository and struct repository_settings. This architectural \nimprovement will:\n\n- Enhance code maintainability by making dependencies explicit.\n- Reduce the risk of unintended side effects from global state \nmodifications.\n- Improve Git's ability to handle multiple repositories within the same \nprocess.\n\n### Expected Project Size: 90 Hours\n\n## Key Tasks\n\n1. Identifying Global State Variables\n- Analyze environment.c and related files to locate global variables.\n- Identify the functions and modules that rely on these global \nvariables, and list all files using each variable.\n- Categorize these variables based on their use cases and potential \nmigration targets.\n- Write Documentation listing all desired variable migration, allowing \nfor community contribution.\n- Discuss prioritization with the community and designate priority of \ntasks.\n\n2. Refactoring Process\n- Move identified global variables into struct repository or struct \nrepository_settings.\n- Ensure proper initialization and access mechanisms to maintain \ncurrent behavior.\n- Updating Affected Code Paths\n- Modify functions and modules that rely on the old global state.\n- Ensure all relevant operations correctly pass repository-specific \ncontext.\n\n3. Testing and Validation\n- Run Git's extensive test suite to verify functionality remains intact.\n- Update or create new tests as needed to cover refactored components.\n\n4. Documentation\n— Document changes in Git's developer notes.\n— Provide clear explanations for new structures and access patterns.\n\n5. Challenges and Considerations\n- Ensuring backward compatibility and avoiding regressions.\n- Handling dependencies between different parts of the codebase that \nrely on global state.\n- Keeping performance overhead minimal while introducing structured \nstate management.\n\n## Schedule\n1. **Now -- May 5th**: Exploration of codebase\n- Research and familiarize with environment.c and related code. \n- Identify global variables to refactor.\n- Engage with the Git community for feedback.\n\n2. **May 6th -- June 1st**: Community bonding\n- Get in touch with the mentors;\n- Present to the community a first list of variable migrations;\n- Receive feedback from the community and modify project plans;\n- Present potential changes to ensure they align with community goals;\n\n3. **June 2nd -- July 7th**: First coding period\n- Eliminate dependencies on “the_repository” following priority;\n- Identify possible patterns in refactoring and document for future \ncontributors;\n\n4. **July 8th -- August 10th**: Second coding period\n- Move other global variables into local repository contexts;\n- Identify possible patterns in refactoring and document for future \ncontributors;\n\n5. **August 11 -- August 25th**: Documentation period\n- Finalize and refine changes;\n- Document changes, the process, and outline future work regarding \nreducing the global namespace;\n\n## Availability\nI will be working over the summer, but regularly code and study outside \nof work/school hours. I will be dedicating all of this extra time \ntowards this project, but I acknowledge that I will not be able to spend \nan incredibly large amount of time, thus I have chosen my expected \nproject size to be 90 hours. I will be fully available outside of \nworking hours to this task, and will set up a compatible schedule \nwith my mentor(s) in order to ensure that an effective line of \ncommunication is established.\n\nI appreciate your time in reviewing this proposal and look forward to \nyour feedback!\nThank you, \n\nAnthony Wang\n(He/him/his)\n\n\n\n"},{"id":"515721","messageId":"08ace3a3-1eec-499c-a1f8-350832ed7519@gmail.com","threadId":"63259","inReplyTo":"20250405104124.25272-1-anthonywang03@icloud.com","subject":"Re: [GSoC] [RFC] Project Proposal: Refactoring in order to reduce Git's global state","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2025-04-06T18:15:27Z","receivedAt":"2025-04-06T18:15:49Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Anthony,\n\nOn 05/04/25 16:11, Anthony Wang wrote:\n> \n> I'm interested in working with Git over the summer to \"Refactor in Order\n> to Reduce Git's Global State.\" My main motivation for choosing this idea\n> is that improving Git's environment handling will enhance long-term\n> maintainability and scalability, and allow for multiple-repository\n> interactions.\n> \n\nThank you for your proposal! It seems you're starting a bit late in the \ncycle. Anyways, just wanted to send in a gentle reminder that the \nproposal submission deadline is April 8 18:00 UTC. So, there's very less \ntime until the same. You may want to consider submitted your current \nproposal and use the option provided in the GSoC website to update the \nproposal before the due date (if necessary). This would help avoid a \nlast minute rush.\n\nAlso, a feedback about your proposal. You would need to include the \ndetail about the microproject you've worked on and the state of the same \nin the proposal. This helps us while reviewing the proposals.\n\nFeel free to let me know in case you face any difficulty with submitting \nyour proposal.\n\n--\nSivaraam\n"},{"id":"515786","messageId":"20250407171026.49901-1-anthonywang03@icloud.com","threadId":"63259","inReplyTo":"20250405104124.25272-1-anthonywang03@icloud.com","subject":"[GSoC] [RFC] Project Proposal v2: Refactoring in order to reduce Git's global state","fromName":"Anthony Wang","fromEmail":"anthonywang513@gmail.com","sentAt":"2025-04-07T17:10:25Z","receivedAt":"2025-04-07T17:10:31Z","isPatch":false,"sender":{"key":"anthonywang513@gmail.com","avatar":"https://avatars.githubusercontent.com/u/71832477?v=4"},"body":"From: Anthony Wang <anthonywang513@gmail.com>\n\nHi all,\n\nI'm interested in working with Git over the summer to \"Refactor in Order \nto Reduce Git's Global State.\" My main motivation for choosing this idea \nis that improving Git's environment handling will enhance long-term \nmaintainability and scalability, and allow for multiple-repository \ninteractions. \n\nThis is the second version of my proposal. I would love to \nreceive feedback on the content or structure, especially on the points \npertaining to the actual implementation of the project and planned work. \nI will also discuss my past experience, and speak on why I believe I \nwill be able to effectively contribute in a sustainable way to this \nlarge undertaking.\nThanks!\n\n-------------------------------------\n\n# Refactoring in Order to Reduce Git’s Global State\n\n### Personal Info\nName: Anthony Wang\nTimezone: Eastern Time (ET)/UTC -5\nGitHub: https://github.com/wang-anthony03\nLinkedIn: https://www.linkedin.com/in/anthonywang03/\n\n## About Me\n\nMy name is Anthony Wang, and I am a 3rd year Computer Science student \nat the University of Virginia. I have experience in software engineering \nand development, particularly in C, Python, and shell scripting. This is \nmy first time working with open source software, and I am incredibly \nexcited to contribute to Git, as I have always wanted to work on \ndeveloping the tools that I use everyday.\n\nMy background includes building scalable automation tools and \ncontributing to infrastructure projects at Verizon. I was able to work \nwith large codebases, and I learned the importance of clean, \nwell-documented code, as well as the challenges of tech-debt leading to \ndifficulties in maintaining code.\n\n## Previous Experience\n\n- Experience using Git extensively in academic and personal projects.\n- Experience working with C as the main language for multiple Computer \nSystems courses.\n- Developed a text editor in C. [1]\n\n## Microproject\n- t8911: avoid using pipes and improve code clarity\nThread: https://public-inbox.org/git/20250405103718.25160-1-anthonywang03@icloud.com/\nStatus: undergoing discussion  \nDescription: In order to expose more testing outputs, we remove the \npiping of `git tag` outputs in order to expose the exit codes. In \naddition, we remove `-q` tags on instances of `grep` to ensure clarity. \nWe also replace `grep` with `test_grep` to provide helpful debug output \nin case of test failure.\n\n\n## Project Proposal\n\n### Objective\nThis project aims to modernize Git's environment handling by refactoring \nthe environment.c code to reduce the reliance on global state. The goal \nis to move environment variables and configuration settings from the \nglobal scope into appropriate local contexts, primarily within struct \nrepository and struct repository_settings. This architectural \nimprovement will:\n\n- Enhance code maintainability by making dependencies explicit.\n- Reduce the risk of unintended side effects from global state \nmodifications.\n- Improve Git's ability to handle multiple repositories within the same \nprocess.\n\n### Expected Project Size: 90 or 175 Hours\n\n## Key Tasks\n\n1. Identifying Global State Variables\n- Analyze environment.c and related files to locate global variables.\n- Identify the functions and modules that rely on these global \nvariables, and list all files using each variable.\n- Categorize these variables based on their use cases and potential \nmigration targets.\n- Write Documentation listing all desired variable migration, allowing \nfor community contribution.\n- Discuss prioritization with the community and designate priority of \ntasks.\n\n2. Refactoring Process\n- Move identified global variables into struct repository or struct \nrepository_settings.\n- Ensure proper initialization and access mechanisms to maintain \ncurrent behavior.\n- Updating Affected Code Paths\n- Modify functions and modules that rely on the old global state.\n- Ensure all relevant operations correctly pass repository-specific \ncontext.\n\n3. Testing and Validation\n- Run Git's extensive test suite to verify functionality remains intact.\n- Update or create new tests as needed to cover refactored components.\n\n4. Documentation\n— Document changes in Git's developer notes.\n— Provide clear explanations for new structures and access patterns.\n\n5. Challenges and Considerations\n- Ensuring backward compatibility and avoiding regressions.\n- Handling dependencies between different parts of the codebase that \nrely on global state.\n- Keeping performance overhead minimal while introducing structured \nstate management.\n\n## Planned Implementation\nI have been examining the codebase to search for global variables \nand have found two major groups:\n\nThe first group is just one variable - `the_repository`. In order \nto refactor the code to remove dependencies on `the_repository`, \nwe would need to adapt the code in various manners. The first would \nbe to start at the lowest level, and modify the code so that it would \ntake in the needed parameters from `the_repository`, removing the \ninternal dependency on `the_repository`. Alternatively, if the \ndependency can simply be resolved by using information from a \ndifferent source, such as a `struct repository`, or other context \ndependent information, such as in [2] or [3],adapt the code to take \nin the information from the alternate source and remove the \ndependency entirely. Following that, move up another level and repeat \nthe process.\n\nThe second group is config variables. Because these are global \nvariables used by multiple subsystems, refactoring is a bit more \ncomplicated. For areas with access to the repository, relocate the \nconfig variable to the according struct that stores that information. \nFor areas without guaranteed access, move the variable into local \ncontext appropriate structure and its constructor, guaranteeing \naccess to the variable. This workflow heavily draws from [4].\n\n\n## Schedule\n1. **Now -- May 5th**: Exploration of codebase\n- Research and familiarize with environment.c and related code. \n- Identify global variables to refactor.\n- Engage with the Git community for feedback.\n\n2. **May 6th -- June 1st**: Community bonding\n- Get in touch with the mentors;\n- Present to the community a first list of variable migrations;\n- Receive feedback from the community and modify project plans;\n- Present potential changes to ensure they align with community goals;\n\n3. **June 2nd -- July 7th**: First coding period\n- Eliminate dependencies on “the_repository” following priority;\n- Identify possible patterns in refactoring and document for future \ncontributors;\n\n4. **July 8th -- August 10th**: Second coding period\n- Move other global variables into local repository contexts;\n- Identify possible patterns in refactoring and document for future \ncontributors;\n\n5. **August 11 -- August 25th**: Documentation period\n- Finalize and refine changes;\n- Document changes, the process, and outline future work regarding \nreducing the global namespace;\n\n## Availability\nI will be working over the summer, but regularly code and study outside \nof work/school hours. I will be dedicating all of this extra time \ntowards this project, but I acknowledge that I will not be able to spend \nan incredibly large amount of time,  thus I have chosen my expected \nproject size to be up to 175 hours if given an extended timeline, and \n90 hours if not. I will be fully available outside of working hours to \nthis task, and will set up a compatible schedule with my mentor(s) in\norder to ensure that an effective line of communication is established.\n\nI appreciate your time in reviewing this proposal and look forward to \nyour feedback!\nThank you, \n\nAnthony Wang\n(He/him/his)\n\nReferences:\n-----------\n\n[1] https://github.com/wang-anthony03/Quill\n\n[2] https://lore.kernel.org/git/20250310-b4-pks-objects-without-the-repository-v4-6-f201b8ec57ba@pks.im/\n\n[3] https://lore.kernel.org/git/20250310-b4-pks-objects-without-the-repository-v4-1-f201b8ec57ba@pks.im/\n\n[4] https://public-inbox.org/git/342a26572d6372d40ba563d73242e0d18a481d2a.1733236936.git.karthik.188@gmail.com/\n\n\n\n"}]}