{"thread":{"id":"63243","subject":"[GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state","startedAt":"2025-04-02T18:14:16Z","lastAt":"2025-04-05T18:41:21Z","messageCount":5,"participants":["Arnav Bhate","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"515525","messageId":"1077615a-1c31-416d-a754-58b36d404289@gmail.com","threadId":"63243","inReplyTo":null,"subject":"[GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state","fromName":"Arnav Bhate","fromEmail":"bhatearnav@gmail.com","sentAt":"2025-04-02T18:14:12Z","receivedAt":"2025-04-02T18:14:16Z","isPatch":false,"sender":{"key":"bhatearnav@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86760472?v=4"},"body":"## Personal Information\n\n- Full name: Arnav Akshaya Bhate\n- Email address: bhatearnav@gmail.com\n- Mobile no.: +91 8291328838\n- Time zone: UTC+05:30\n- Education: IIT Bombay\n- Year: Second year\n- GitHub: https://github.com/arnavbhate\n\n## About Me\n\nI'm Arnav Bhate, a second-year UG student at Indian Institute of\nTechnology Bombay. I love coding and so I am a member of IIT Bombay's\nDevelopers' Community (DevCom), which is a group of roughly 40 people\ndeveloping software for use by students and staff of the institute. Most\nof the software developed is not open source, so I can not include\nexamples of my work there in this proposal. Being a member of DevCom has\nexposed me to collaborative software development.\n\nA common link in all software I have worked on is that Git has been used\nfor version control. I thus see this project as my way of giving back to\nthe Git community in particular and open source in general. This will be\nmy first significant contribution to the open source community, and I\nwish to stick around afterwards.\n\n## Overview\n\nGit currently uses many global variables, most significantly\n`the_repository`, which are included in roughly 290 files. Apart from\n`the_repository`, there are many global variables, some of which\nlogically belong in struct repository, as they represent information\nspecific to a repository. So even if all instances of the_repository\nwere converted into a extra repository argument for the function, there\nwould still be many global variables left.\n\nThe use of such variables assumes that Git will only operate on one\nrepository at a time, which renders multi-repository handling\nimpossible without kludges.\n\nThis project aims to move such variables from global scope into more\nappropriate local contexts, mainly `struct repository` and\n`struct repository_settings`. This will not only make the environment\nrepository-specific, allowing easy multi-repository handling, but also\nmake maintaining the code easier.\n\nThe project involves identifying suitable locations for environment\nvariables in repository specific structs, moving them there and updating\nall the code affected by the move.\n\n## Pre-GSoC\n\nI first got into Git's codebase in February 2025, with my first\ncontribution in March. My first patch was on my microproject and since\nthen I have submitted two more patches on a similar topic.\n\n### Patches\n\n- (Microproject) decorate: fix sign comparison warnings  \n  Thread: https://lore.kernel.org/git/afa6b428-3190-42ae-9eac-540c95b576fd@gmail.com/  \n  Status: Merged into master  \n  Commit hash: 2bfd3b368572cbf1ce287de09db08b7e7e429ecd  \n  Description: Refactoring of decorate.c to replace signed variables\n  with unsigned ones when they are used to iterate over arrays whose\n  sizes are represented by unsigned variables, and remove 2 unnecessary\n  variables which just hold the value of another variable without being\n  modified, replacing them with the variable whose value they were\n  holding.\n\n- rm: fix sign comparison warnings  \n  Thread: https://lore.kernel.org/git/38de63ce-6d4e-4f1f-95b1-049df78d9cfc@gmail.com/  \n  Status: Under discussion  \n  Description: Refactoring of rm.c to make iterators over arrays whose\n  sizes are represented by unsigned variables unsigned. Specifically in\n  `get_ours_cache_pos`, where before a signed variable was being passed\n  and then inverted in the function, now the already inverted variable\n  is passed as an unsigned variable, with the inversion moved to the\n  function call.\n\n- pathspec: fix sign comparison warnings  \n  Thread: https://lore.kernel.org/git/a3aa5f99-63ce-4be5-8d64-fb6e226b3bf9@gmail.com/  \n  Status: under discussion  \n  Description: Refactoring of pathspec.c to make array iterator\n  variables match the type of the variable storing the array's size.\n  Where replacing the variable's type is not possible, because of the\n  large-scale cascade replacements it would cause, an appropriate cast\n  has been added.\n\n## Proposed Plan\n\n- Identifying all occurences of `the_repository` and updating them to\n  use a `struct repository` passed to the function.\n\n- Identifying global variables that should be moved and identifying\n  suitable locations, some could be moved directly into\n  `struct repository`, some in its sub-structs that already exist and\n  some in newly created sub-structs.\n\n- Identifying and updating occurences of these variables to reference\n  their new locations.\n\nIt makes sense that all the variables need not be in the same struct, as\nseparation would keep the codebase organised, and thus easier to\nmaintain. It would also make it easier to introduce these changes\nsystematically, as a group of related variables, combined together in a\nstruct, could be introduced in a single patch series.\n\n### Timeline\n\n#### Pre-GSoC (Until May 8)\n\n- Explore the codebase, identifying global variables and how they are\n  used.\n\n- Start to identify suitable locations for global variables.\n\n#### Community Bonding Period (May 8 - June 1)\n\n- Interact with mentor, discussing best ways to refactor various\n  variables and make a plan based on that.\n\n- If time is left, start coding early, as my summer break will have\n  started.\n\n#### Coding Period (June 2 - August 25)\n\n- Modify functions to add an `struct repository` argument where they\n  depend on `the_repository` and replace all occurences of it.\n\n- Move global variables to their new locations in various structs,\n  and refactor functions that depend on them to use their new locations.\n\n#### Final Week (August 25 - September 1)\n\n- Fix any bugs that may be left.\n\n- Write final report.\n\n### Availability\n\nMy summer break from college lasts from May to July. I am currently\nplanning on taking a vacation during this period of about 1 week,\nhowever, the dates have not been decided. Outside of this vacation, I\nam not occupied in the break and can devote up to 60 hours a week\ntowards the project. In August, once classes recommence, I will be\navailable for 20 hours a week.\n\n## Post-GSoC\n\nAfter completing my project, I plan on staying active and contributing\npatches, and start reviewing code.\n\n-- \nRegards,\nArnav Bhate\n(He/Him)\n\n"},{"id":"515572","messageId":"Z-5b6INZXiXbEuU2@pks.im","threadId":"63243","inReplyTo":"1077615a-1c31-416d-a754-58b36d404289@gmail.com","subject":"Re: [GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-03T09:59:04Z","receivedAt":"2025-04-03T09:59:12Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote:\n[snip]\n> ## Proposed Plan\n> \n> - Identifying all occurences of `the_repository` and updating them to\n>   use a `struct repository` passed to the function.\n\nI think that might be overly ambituous :) After all we're talking about\n~3500 occurrences, and it won't be feasible to replace them all in the\ncouple of months. This is rather a multi-year project, and one that has\nalready been going on for quite a while.\n\n> - Identifying global variables that should be moved and identifying\n>   suitable locations, some could be moved directly into\n>   `struct repository`, some in its sub-structs that already exist and\n>   some in newly created sub-structs.\n\nLikewise, I would recommend to properly scope _which_ variables you want\nto replace. There's a ton of global state, so you should try to limit\nthe project to a reasonable workload.\n\n> - Identifying and updating occurences of these variables to reference\n>   their new locations.\n> \n> It makes sense that all the variables need not be in the same struct, as\n> separation would keep the codebase organised, and thus easier to\n> maintain. It would also make it easier to introduce these changes\n> systematically, as a group of related variables, combined together in a\n> struct, could be introduced in a single patch series.\n> \n> ### Timeline\n> \n> #### Pre-GSoC (Until May 8)\n> \n> - Explore the codebase, identifying global variables and how they are\n>   used.\n> \n> - Start to identify suitable locations for global variables.\n> \n> #### Community Bonding Period (May 8 - June 1)\n> \n> - Interact with mentor, discussing best ways to refactor various\n>   variables and make a plan based on that.\n> \n> - If time is left, start coding early, as my summer break will have\n>   started.\n> \n> #### Coding Period (June 2 - August 25)\n> \n> - Modify functions to add an `struct repository` argument where they\n>   depend on `the_repository` and replace all occurences of it.\n> \n> - Move global variables to their new locations in various structs,\n>   and refactor functions that depend on them to use their new locations.\n\nIn large-scale projects like these it typically makes sense to work in\nbatches. Instead of having three separate phases to \"define the\nproblem\", \"develop the solution\" and \"deploy the improvement\" I would\nstrongly encourage you to define and tie together smaller batches of\nwork.\n\nThanks!\n\nPatrick\n"},{"id":"515591","messageId":"bcdeb3cf-33a1-4553-897d-0bc09dc6a78d@gmail.com","threadId":"63243","inReplyTo":"Z-5b6INZXiXbEuU2@pks.im","subject":"Re: [GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state","fromName":"Arnav Bhate","fromEmail":"bhatearnav@gmail.com","sentAt":"2025-04-03T15:26:45Z","receivedAt":"2025-04-03T15:26:49Z","isPatch":false,"sender":{"key":"bhatearnav@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86760472?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n> On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote:\n> [snip]\n>> ## Proposed Plan\n>>\n>> - Identifying all occurences of `the_repository` and updating them to\n>>   use a `struct repository` passed to the function.\n> \n> I think that might be overly ambituous :) After all we're talking about\n> ~3500 occurrences, and it won't be feasible to replace them all in the\n> couple of months. This is rather a multi-year project, and one that has\n> already been going on for quite a while.\n> \n>> - Identifying global variables that should be moved and identifying\n>>   suitable locations, some could be moved directly into\n>>   `struct repository`, some in its sub-structs that already exist and\n>>   some in newly created sub-structs.\n> \n> Likewise, I would recommend to properly scope _which_ variables you want\n> to replace. There's a ton of global state, so you should try to limit\n> the project to a reasonable workload.\n\nI could do all the global variables in environment.c. I feel like that\nis doable. Once I am finished with that, I could start replacing\nthe_repository.\n\n>> - Identifying and updating occurences of these variables to reference\n>>   their new locations.\n>>\n>> It makes sense that all the variables need not be in the same struct, as\n>> separation would keep the codebase organised, and thus easier to\n>> maintain. It would also make it easier to introduce these changes\n>> systematically, as a group of related variables, combined together in a\n>> struct, could be introduced in a single patch series.\n>>\n>> ### Timeline\n>>\n>> #### Pre-GSoC (Until May 8)\n>>\n>> - Explore the codebase, identifying global variables and how they are\n>>   used.\n>>\n>> - Start to identify suitable locations for global variables.\n>>\n>> #### Community Bonding Period (May 8 - June 1)\n>>\n>> - Interact with mentor, discussing best ways to refactor various\n>>   variables and make a plan based on that.\n>>\n>> - If time is left, start coding early, as my summer break will have\n>>   started.\n>>\n>> #### Coding Period (June 2 - August 25)\n>>\n>> - Modify functions to add an `struct repository` argument where they\n>>   depend on `the_repository` and replace all occurences of it.\n>>\n>> - Move global variables to their new locations in various structs,\n>>   and refactor functions that depend on them to use their new locations.\n> \n> In large-scale projects like these it typically makes sense to work in\n> batches. Instead of having three separate phases to \"define the\n> problem\", \"develop the solution\" and \"deploy the improvement\" I would\n> strongly encourage you to define and tie together smaller batches of\n> work.\n\nWhat I meant is, before coding started, I want to finalise all the new\nlocations for the global variables with my mentor, then I would actually\nmodify the code in batches, struct-by-struct. Are you suggesting that\nthe new locations not be finalised beforehand, or are we misinterpreting\neach other?\n\n> Thanks!\n> \n> Patrick\n\n-- \nRegards,\nArnav Bhate\n(He/Him)\n\n"},{"id":"515646","messageId":"Z--kCrCnl3Zw4YG7@pks.im","threadId":"63243","inReplyTo":"bcdeb3cf-33a1-4553-897d-0bc09dc6a78d@gmail.com","subject":"Re: [GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-04T09:19:06Z","receivedAt":"2025-04-04T09:19:10Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Apr 03, 2025 at 08:56:45PM +0530, Arnav Bhate wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> > On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote:\n> >> ### Timeline\n> >>\n> >> #### Pre-GSoC (Until May 8)\n> >>\n> >> - Explore the codebase, identifying global variables and how they are\n> >>   used.\n> >>\n> >> - Start to identify suitable locations for global variables.\n> >>\n> >> #### Community Bonding Period (May 8 - June 1)\n> >>\n> >> - Interact with mentor, discussing best ways to refactor various\n> >>   variables and make a plan based on that.\n> >>\n> >> - If time is left, start coding early, as my summer break will have\n> >>   started.\n> >>\n> >> #### Coding Period (June 2 - August 25)\n> >>\n> >> - Modify functions to add an `struct repository` argument where they\n> >>   depend on `the_repository` and replace all occurences of it.\n> >>\n> >> - Move global variables to their new locations in various structs,\n> >>   and refactor functions that depend on them to use their new locations.\n> > \n> > In large-scale projects like these it typically makes sense to work in\n> > batches. Instead of having three separate phases to \"define the\n> > problem\", \"develop the solution\" and \"deploy the improvement\" I would\n> > strongly encourage you to define and tie together smaller batches of\n> > work.\n> \n> What I meant is, before coding started, I want to finalise all the new\n> locations for the global variables with my mentor, then I would actually\n> modify the code in batches, struct-by-struct. Are you suggesting that\n> the new locations not be finalised beforehand, or are we misinterpreting\n> each other?\n\nThe problem I see is that you only have one large \"Coding Period\". What\nwe would like to see though is that you define smaller, self-contained\nbatches of work that you can try to land individually, as well as an\nestimation around how long each of these batches will take you to both\ndevelopend and land in Git itself.\n\nPatrick\n"},{"id":"515701","messageId":"7116fc77-2280-4bd1-b2f2-131e1108b8ce@gmail.com","threadId":"63243","inReplyTo":"1077615a-1c31-416d-a754-58b36d404289@gmail.com","subject":"[GSoC PROPOSAL v2] Refactoring in order to reduce Git’s global state","fromName":"Arnav Bhate","fromEmail":"bhatearnav@gmail.com","sentAt":"2025-04-05T18:41:16Z","receivedAt":"2025-04-05T18:41:21Z","isPatch":false,"sender":{"key":"bhatearnav@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86760472?v=4"},"body":"## Personal Information\n\n- Full name: Arnav Akshaya Bhate\n- Email address: bhatearnav@gmail.com\n- Mobile no.: +91 8291328838\n- Time zone: UTC+05:30\n- Education: IIT Bombay\n- Year: Second year\n- GitHub: https://github.com/arnavbhate\n\n## About Me\n\nI'm Arnav Bhate, a second-year UG student at Indian Institute of\nTechnology Bombay. I love coding and so I am a member of IIT Bombay's\nDevelopers' Community (DevCom), which is a group of roughly 40 people\ndeveloping software for use by students and staff of the institute. Most\nof the software developed is not open source, so I can not include\nexamples of my work there in this proposal. Being a member of DevCom has\nexposed me to collaborative software development.\n\nA common link in all software I have worked on is that Git has been used\nfor version control. I thus see this project as my way of giving back to\nthe Git community in particular and open source in general. This will be\nmy first significant contribution to the open source community, and I\nwish to stick around afterwards.\n\n## Overview\n\nGit currently uses many global variables, most significantly\n`the_repository`, which are included in roughly 290 files. Apart from\n`the_repository`, there are many global variables, some of which\nlogically belong in struct repository, as they represent information\nspecific to a repository. So even if all instances of the_repository\nwere converted into a extra repository argument for the function, there\nwould still be many global variables left.\n\nThe use of such variables assumes that Git will only operate on one\nrepository at a time, which renders multi-repository handling\nimpossible without kludges.\n\nThis project aims to move such variables from global scope into more\nappropriate local contexts, mainly `struct repository` and\n`struct repository_settings`. This will not only make the environment\nrepository-specific, allowing easy multi-repository handling, but also\nmake maintaining the code easier.\n\nThe project involves identifying suitable locations for environment\nvariables in repository specific structs, moving them there and updating\nall the code affected by the move.\n\n## Pre-GSoC\n\nI first got into Git's codebase in February 2025, with my first\ncontribution in March. My first patch was on my microproject and since\nthen I have submitted two more patches on a similar topic.\n\n### Patches\n\n- (Microproject) decorate: fix sign comparison warnings  \n  Thread: https://lore.kernel.org/git/afa6b428-3190-42ae-9eac-540c95b576fd@gmail.com/  \n  Status: Merged into master  \n  Commit hash: 2bfd3b368572cbf1ce287de09db08b7e7e429ecd  \n  Description: Refactoring of decorate.c to replace signed variables\n  with unsigned ones when they are used to iterate over arrays whose\n  sizes are represented by unsigned variables, and remove 2 unnecessary\n  variables which just hold the value of another variable without being\n  modified, replacing them with the variable whose value they were\n  holding.\n\n- rm: fix sign comparison warnings  \n  Thread: https://lore.kernel.org/git/38de63ce-6d4e-4f1f-95b1-049df78d9cfc@gmail.com/  \n  Status: Under discussion  \n  Description: Refactoring of rm.c to make iterators over arrays whose\n  sizes are represented by unsigned variables unsigned. Specifically in\n  `get_ours_cache_pos`, where before a signed variable was being passed\n  and then inverted in the function, now the already inverted variable\n  is passed as an unsigned variable, with the inversion moved to the\n  function call.\n\n- pathspec: fix sign comparison warnings  \n  Thread: https://lore.kernel.org/git/a3aa5f99-63ce-4be5-8d64-fb6e226b3bf9@gmail.com/  \n  Status: Under discussion  \n  Description: Refactoring of pathspec.c to make array iterator\n  variables match the type of the variable storing the array's size.\n  Where replacing the variable's type is not possible, because of the\n  large-scale cascade replacements it would cause, an appropriate cast\n  has been added.\n\n- environment.h: remove unused variables\n  Thread: https://lore.kernel.org/git/2c547567-2b72-476c-9fc5-71cac050fa15@gmail.com/\n  Status: Under discussion\n  Description: Removing two variables which did not have any references\n  in the codebase, as they had been moved to `struct repo_settings`, but\n  were not removed from environment.h.\n\n## Proposed Plan\n\n- Identifying global variables in environment.c that should be moved and\n  identifying suitable locations, some could be moved directly into\n  `struct repository`, some in its sub-structs that already exist and\n  some in newly created sub-structs.\n\n- Identifying and updating occurrences of these variables to reference\n  their new locations.\n\n- Identifying all occurrences of `the_repository` and updating them to\n  use a `struct repository` passed to the function.\n\nIt makes sense that all the variables need not be in the same struct, as\nseparation would keep the codebase organised, and thus easier to\nmaintain. It would also make it easier to introduce these changes\nsystematically, as a group of related variables, combined together in a\nstruct, could be introduced in a single patch series.\n\n### Timeline\n\n#### Pre-GSoC (Until May 8)\n\n- Explore the codebase, identifying locations where global variables\n  from environment.c are used.\n\n- Identify suitable locations for these global variables.\n\n#### Community Bonding Period (May 8 - June 1)\n\n- Interact with mentor, discussing the locations I have decided, and\n  refining the plan if required.\n\n- Start coding early, as my summer break will have started. (See coding\n  period)\n\n#### Coding Period (June 2 - August 25)\n\n- Move global variables to their new locations in various structs,\n  and refactor functions that depend on them to use their new locations.\n\n  - Variables which represent settings from config (7 weeks)\n    - Core (5 weeks)\n    - Others (2 weeks)\n  - Variables not from config (3 weeks)\n\n- Modify functions to add an `struct repository` argument where they\n  depend on `the_repository` and replace all occurrences of it in the\n  function.\n\n#### Final Week (August 25 - September 1)\n\n- Fix any bugs that may be left.\n\n- Write final report.\n\n### Availability\n\nMy summer break from college lasts from May to July. I am currently\nplanning on taking a vacation during this period of about 1 week,\nhowever, the dates have not been decided. Outside of this vacation, I\nam not occupied in the break and can devote up to 60 hours a week\ntowards the project. In August, once classes recommence, I will be\navailable for 20 hours a week.\n\n## Post-GSoC\n\nAfter completing my project, I plan on staying active and contributing\npatches, and start reviewing code.\n-- \nRegards,\nArnav Bhate\n(He/Him)\n\n"}]}