{"thread":{"id":"64403","subject":"[Outreachy][Proposal]: Refactor in order to reduce Git’s global state","startedAt":"2025-10-29T01:18:53Z","lastAt":"2025-11-01T19:13:48Z","messageCount":7,"participants":["Bello Olamide","Christian Couder","Olamide Caleb Bello"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"529849","messageId":"CAD=f0L9anYu4LKWGDKrwzBBytMunJ3UjTehNN9m2DigG8yCNHA@mail.gmail.com","threadId":"64403","inReplyTo":null,"subject":"[Outreachy][Proposal]: Refactor in order to reduce Git’s global state","fromName":"Bello Olamide","fromEmail":"belkid98@gmail.com","sentAt":"2025-10-29T01:18:53Z","receivedAt":"2025-10-29T01:18:53Z","isPatch":false,"sender":{"key":"belkid98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/73387291?v=4"},"body":"Hello,\nThis is my proposal for the project\n\"Refactor in order to reduce Git’s global state\" for the 2025 Outreachy\nInternship program.\n\nPersonal Bio:\n===========\nFull Name: Bello Caleb Olamide\nEmail: belkid98@gmail.com\nPersonal Blog: https://cloobtech.hashnode.dev/\nGitHub: https://github.com/cloobtech\n\nAbout Me:\n=========\nI'm Bello Olamide. I am passionate about software engineering and\nI love to figure out things. I like participating in tech\nevents such as hackathons but this will be my first open source experience\nand I have relished the opportunity and experience so far.\nI love being part of a community that strive to achieve a goal and one that\nI found myself is a small albeit growing community that helps to guide and\nmentor younger boys find their way into the tech ecosystem. I have developed\nmy coding skill via various sources including personal learning, freelancing,\ncollaboration with other developers and from the ALX Software Engineering\nprogram.\n\nPast Experience with Git:\n===================\nI have been a Git user for sometime now majorly for collaborating with other\ndevelopers, tracking version changes to files and during this contribution\nstage, I have understood the ropes of how to send patches to Git.\n\nContributions to the Git Community:\n==========================\nI have been able to send some patches to the Git codebase with the guidance\nand direction of community members.\n\nMicroproject:\n==========\nLink: https://lore.kernel.org/git/cover.1761217100.git.belkid98@gmail.com/\nBranch: ob/gpg-interface-cleanup\nStatus: Merged to next\nCommit ID: ce6d041635\nDescription: strbuf_split*() to split a string into multiple strbufs\nis often a wrong API to use.\nA few uses of it have been removed by simplifying the code.\n\nProject Overview\n=============\nGit uses a single global `struct repository` object called `the_repository`\nwhich internal functions rely on to store, access and modify environment\nand configuration variables.\nWith this approach, multi-repository instances running in the same process\ncan lead to inconsistent behaviours and race conditions.\nBy refactoring the code to stop storing repository-scoped\nconfigurations in global variables in\n`environment.c file`, that is by moving the appropriate global\nvariables into localised state\nwithin the `struct repository` and `struct repo-settings`, the\ncodebase becomes more maintainable,\neasier to test and future work such as libifying Git becomes feasible.\n\nInternship Objectives and Plans\n========================\nThe project aims to identify repository scoped global variables in\n`environment.c`\nand related files that can be moved to local scope within `struct\nrepository` and\n`struct repo-settings`, find an appropriate strategy to move them to\nlocal scope and implement the changes. This architectural improvement\nwill make the\ncodebase more maintainable and enable better multi-repository handling\nin the future.\n\nFrom a high level overview, environment.[ch] exposes some global\nvariables that reflect a per-repository state and examples of such include\ngit_work_tree_cfg, is_bare_repository_cfg, and core.* settings and functions\nwhich also depend on `the_repository` such as have_git_dir(),\nis_bare_repository().\nAfter a brief study of some related work done on the project,\nit is important to understand the purpose of the identified global variable\nand how it is used across the code base, observing how it relates with other\nsubsystems and moving it to the `struct repository` or `struct\nrepo-settings` if its\nuse is repository specific, or specify an appropriate context based on its scope\nand use this context in the accessor functions.\nFor example in [1], Patrick Steinhardt observes that `core.hooksPath`\nis repository specific and is stored in the global variable `git_hooks_path`.\nThe variable is then moved into local scope in the repo-settings\nstruct and a new\naccessor function `repo_settings_get_hooks_path()` is written and used to\nset the `hooks_path` of the repo specific struct which the path subsystem\nreads from.\nSimilarly in [2], `core.sharedRepository` is tracked via the global variables\n`the_shared_repository ` and `need_shared_repository`. These are then\nmoved into the repo-settings struct, with new accessors functions\nwritten to modify them,\nand calls to the accessors in the path subsystem are then modified to\nreplace the old\naccessors which modify the global variables.\n\nI also studied [3], [4] by Ayush Chandeker,] and [5] by John Cai to broaden my\nunderstanding of the project.\n\nProposed Project Execution Timeline\n=========================\n\n1. Study Code Base To Identify Suitable Candidates (Now - December 8, 2025):\n------------------------------------------------------------------------\n- The first step will be familiarising myself with the code base to\n understand how these global variables in environment.c are initialised,\n used and how they interact with other subsystems.\n\n2. Community Feedback Bonding ( December 9 - December 15, 2025):\n------------------------------------------------------------\n- Discuss environment variables with mentors and community members\n- Understand best refactoring approach based on feedback from mentors\n\n3. Review Existing Patch and Define Criteria (December 16 - January 9, 2026):\n-------------------------------------------------------------\n- Thoroughly examine the existing patch series submitted to the mailing\n list to understand;\n * What criteria makes a global variable a suitable candidate to be\n moved to the `struct repository` or `struct repo-settings`\n * What appropriate context it should be moved into based on its\n interactions with other subsystems.\n * If remaining a global variable is the best approach in its case.\n- This information can be gotten by paying attention to the discussions\nin the patches and also engaging with my mentors and the Git community.\n\n4. Implement Candidates and Submit PRs ( January 10 - February 28, 2026):\n--------------------------------------------------------------------------\n- With collaboration from mentors and the Git community, identify\nsuitable candidates for relocation.\n- Relocate them into `struct repository`, `struct repo-settings` and\nother appropriate\ncontexts.\n- Pass the repository parameter to accessor functions to replace the\nglobal dependence\n- Write new accessor functions if necessary\n- Modify accessor callers to reflect the new changes while ensuring\nall affected code paths works\n correctly\n- Update tests and documentations\n- Recursively submit patches for reviews, engaging in discussions and\nimplement suggestions\n\n5. Final Report on Project (February 29 - March 6)\n--------------------------------\n- Document final report in my blog with details on my experience\n- Finalize any pending tasks or reviews on any submitted patch\n\nAvailability\n========\nI am currently not enrolled in any school or jobs, so I will be able to give\n30 hours a week or more to make the project a success.\n\nBlogging\n=======\nI have set up my blog where i will document my progress, insights,\nchallenges and experience weekly.\n\nPost Outreachy\n====================\nThe welcoming and patient atmosphere during this short contribution\nperiod with the Git\ncommunity has made me want to keep getting involved with the\ncommunity. I am committed to\ncontinuously contributing to Git and become a part of of the next set\nof contributors\nto champion the continuous development of Git.\n\nAppreciation\n==========\nTo Junio and Christian, I really appreciate your guidance, patience\nand direction while\nreviewing and helping with my patches and to Usman for your inputs and to every\nmember of the Git community, I thank you all.\n\nReferences\n=========\n[1]: https://public-inbox.org/git/20250207-b4-pks-path-drop-the-repository-v2-14-13cad3c11b8a@pks.im/#Z31config.c\n[2]: https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-15-4e77f0313206@pks.im/\n[3]: https://lore.kernel.org/git/d0e2042b3061320fac8a8fdf9043c6ab4dbed5a2.1752882401.git.ayu.chandekar@gmail.com/\n[4]: https://lore.kernel.org/git/c82620a1f54ea6760bff204fd2b5fe5c2df1896c.1753804956.git.ayu.chandekar@gmail.com/\n[5]: https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n"},{"id":"529872","messageId":"CAP8UFD0a+RxQ-pPWrmwOYhBic6Oy9C1NeA7EmEyj2KYYDyS4QA@mail.gmail.com","threadId":"64403","inReplyTo":"CAD=f0L9anYu4LKWGDKrwzBBytMunJ3UjTehNN9m2DigG8yCNHA@mail.gmail.com","subject":"Re: [Outreachy][Proposal]: Refactor in order to reduce Git’s global state","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-29T15:51:09Z","receivedAt":"2025-10-29T15:51:23Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Oct 29, 2025 at 2:18 AM Bello Olamide wrote:\n>\n> Hello,\n> This is my proposal for the project\n> \"Refactor in order to reduce Git’s global state\" for the 2025 Outreachy\n> Internship program.\n\nThanks for this proposal.\n\n[...]\n\n> From a high level overview, environment.[ch] exposes some global\n> variables that reflect a per-repository state and examples of such include\n> git_work_tree_cfg, is_bare_repository_cfg, and core.* settings and functions\n> which also depend on `the_repository` such as have_git_dir(),\n> is_bare_repository().\n> After a brief study of some related work done on the project,\n> it is important to understand the purpose of the identified global variable\n> and how it is used across the code base, observing how it relates with other\n> subsystems and moving it to the `struct repository` or `struct\n> repo-settings` if its\n> use is repository specific, or specify an appropriate context based on its scope\n> and use this context in the accessor functions.\n> For example in [1], Patrick Steinhardt observes that `core.hooksPath`\n> is repository specific and is stored in the global variable `git_hooks_path`.\n> The variable is then moved into local scope in the repo-settings\n> struct and a new\n> accessor function `repo_settings_get_hooks_path()` is written and used to\n> set the `hooks_path` of the repo specific struct which the path subsystem\n> reads from.\n> Similarly in [2], `core.sharedRepository` is tracked via the global variables\n> `the_shared_repository ` and `need_shared_repository`. These are then\n> moved into the repo-settings struct, with new accessors functions\n> written to modify them,\n> and calls to the accessors in the path subsystem are then modified to\n> replace the old\n> accessors which modify the global variables.\n\nNit: the above paragraph looks very big. Maybe it could be split a bit.\n\n> I also studied [3], [4] by Ayush Chandeker,] and [5] by John Cai to broaden my\n> understanding of the project.\n\nAre there some cases where strategies other than writing new accessors\nfunctions were used?\n\nAre there pieces of work on this that were started but not finished?\nAre you planning to finish them?\n\nWhat are the roadblocks that were faced when working on this?\n\n> 3. Review Existing Patch and Define Criteria (December 16 - January 9, 2026):\n> -------------------------------------------------------------\n> - Thoroughly examine the existing patch series submitted to the mailing\n> list to understand;\n> * What criteria makes a global variable a suitable candidate to be\n> moved to the `struct repository` or `struct repo-settings`\n> * What appropriate context it should be moved into based on its\n> interactions with other subsystems.\n> * If remaining a global variable is the best approach in its case.\n> - This information can be gotten by paying attention to the discussions\n> in the patches and also engaging with my mentors and the Git community.\n\nAre you sure that it will be possible to define clear criteria?\n\nThanks.\n"},{"id":"529952","messageId":"CAD=f0L8=eBJjj77xBw7m7WcQf80sYbF-X1wbFc9ToC9F0AWVAQ@mail.gmail.com","threadId":"64403","inReplyTo":"CAP8UFD0a+RxQ-pPWrmwOYhBic6Oy9C1NeA7EmEyj2KYYDyS4QA@mail.gmail.com","subject":"Re: [Outreachy][Proposal]: Refactor in order to reduce Git’s global state","fromName":"Bello Olamide","fromEmail":"belkid98@gmail.com","sentAt":"2025-10-30T10:59:57Z","receivedAt":"2025-10-30T10:59:56Z","isPatch":false,"sender":{"key":"belkid98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/73387291?v=4"},"body":"On Wed, 29 Oct 2025 at 16:51, Christian Couder\n wrote:\n>\n> Hi,\n>\n> On Wed, Oct 29, 2025 at 2:18 AM Bello Olamide wrote:\n> >\n> > Hello,\n> > This is my proposal for the project\n> > \"Refactor in order to reduce Git’s global state\" for the 2025 Outreachy\n> > Internship program.\n>\n> Thanks for this proposal.\n>\n> [...]\n>\n> > From a high level overview, environment.[ch] exposes some global\n> > variables that reflect a per-repository state and examples of such include\n> > git_work_tree_cfg, is_bare_repository_cfg, and core.* settings and functions\n> > which also depend on `the_repository` such as have_git_dir(),\n> > is_bare_repository().\n> > After a brief study of some related work done on the project,\n> > it is important to understand the purpose of the identified global variable\n> > and how it is used across the code base, observing how it relates with other\n> > subsystems and moving it to the `struct repository` or `struct\n> > repo-settings` if its\n> > use is repository specific, or specify an appropriate context based on its scope\n> > and use this context in the accessor functions.\n> > For example in [1], Patrick Steinhardt observes that `core.hooksPath`\n> > is repository specific and is stored in the global variable `git_hooks_path`.\n> > The variable is then moved into local scope in the repo-settings\n> > struct and a new\n> > accessor function `repo_settings_get_hooks_path()` is written and used to\n> > set the `hooks_path` of the repo specific struct which the path subsystem\n> > reads from.\n> > Similarly in [2], `core.sharedRepository` is tracked via the global variables\n> > `the_shared_repository ` and `need_shared_repository`. These are then\n> > moved into the repo-settings struct, with new accessors functions\n> > written to modify them,\n> > and calls to the accessors in the path subsystem are then modified to\n> > replace the old\n> > accessors which modify the global variables.\n>\n> Nit: the above paragraph looks very big. Maybe it could be split a bit.\n\nOkay I will do that, thank you\n>\n> > I also studied [3], [4] by Ayush Chandeker,] and [5] by John Cai to broaden my\n> > understanding of the project.\n>\n> Are there some cases where strategies other than writing new accessors\n> functions were used?\n\nYes there were cases where the functions were adapted to use\nexactly what it needs down the call chain rather than writing new\naccessor functions.\nAn example is\nhttps://public-inbox.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/#Z31csum-file.h\nwhere the global variable `the_hash_algo` is replaced with an explicit parameter\n`const struct git_hash_algo *algo` in low-level functions such as\n`static struct hashfile *hashfd_internal()` and the call sites adapted\nto use r->hash_algo\nor the_repository->hash_algo in places where the subsystem has not gotten rid of\n`the-repository`.\n\nThis is also a strategy that can be used to replace global variables.\n>\n> Are there pieces of work on this that were started but not finished?\n> Are you planning to finish them?\n>\n> What are the roadblocks that were faced when working on this?\n>\n\nYes. There were pieces of work that were started but not finished which I plan\nto finish.\nAs an example, the patch\nhttps://lore.kernel.org/git/20250309153321.254844-1-ayu.chandekar@gmail.com/\nattempts to move the `git_attributes_file` global variable to the\n`struct repository`.\nHowever because the global variable is used by the attributes subsystem and\na single repository can have more than one set of attributes, that is\nthe work-tree attributes\nand the index attributes, placing the variable into a repository\ninstance and passing it\naround in the call chain will not be appropriate. Also most of the\nfunctions in the attributes\nsubsystem pass the `index_state` as a parameter and not the repository.\nThis is because an index knows its repository but a repository only knows its\nprimary index. Therefore each repository for an index will need to be known\nfrom the index.\n\nAs Junio pointed out in the discussion on the thread:\n\"As the attribute system is all about giving extra information on the\npaths that appear in the index and in the working tree, it may make\nsense for the API to go from the index state which is about the\nindex and the working tree to access the attributes, rather than\nfrom the repository structure, which controls a lot wider concept\nand moving anything and everything there will easily and quickly\nmake it a messy kitchen sink.\"\n\nSo Given that the `index_state` struct has a repo member, we can move\n'git_attributes_file' into the repo struct but access it through the\n`index_state`.\nBy doing that we know the index truly owns the attributes.\n\nThere is also `is_bare_repository_cfg` as seen in\nhttps://lore.kernel.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\nI have only skimmed through the discussions and patches to understand why it\nwas not finished.\nBut I will do an in depth study to understand why it was not completed and what\nit takes to finish it.\n\n> > 3. Review Existing Patch and Define Criteria (December 16 - January 9, 2026):\n> > -------------------------------------------------------------\n> > - Thoroughly examine the existing patch series submitted to the mailing\n> > list to understand;\n> > * What criteria makes a global variable a suitable candidate to be\n> > moved to the `struct repository` or `struct repo-settings`\n> > * What appropriate context it should be moved into based on its\n> > interactions with other subsystems.\n> > * If remaining a global variable is the best approach in its case.\n> > - This information can be gotten by paying attention to the discussions\n> > in the patches and also engaging with my mentors and the Git community.\n>\n> Are you sure that it will be possible to define clear criteria?\n\nYes it will be possible to define clear criteria per global variable.\nFor example, from my brief study of previous work, if the variable value is:\n\n1. meant to be different for different repositories, it is a candidate\nto move, if not then it is left\n as is, like the case of `local_repo_env[]`.\n\n2. used during early startup, it cannot be moved blindly but will need\na closer inspection\n and refactoring of the startup code as is the case with\n`have_git_dir()` noted by Patrick and\n Shejialuo in\n https://lore.kernel.org/git/20250305104650.238392-1-ayu.chandekar@gmail.com/.\n\nIts relationship with other subsystems is also a criteria to define\nsuch as the case of\n`git_attributes_file mentioned` above\n\nThanks\n"},{"id":"529963","messageId":"CAP8UFD1v7yec7JwBGekJPvcq7kNJPuPTgWOVn+gBaw1+Sh2mdA@mail.gmail.com","threadId":"64403","inReplyTo":"CAD=f0L8=eBJjj77xBw7m7WcQf80sYbF-X1wbFc9ToC9F0AWVAQ@mail.gmail.com","subject":"Re: [Outreachy][Proposal]: Refactor in order to reduce Git’s global state","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-10-30T12:55:14Z","receivedAt":"2025-10-30T12:55:28Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Oct 30, 2025 at 11:59 AM Bello Olamide wrote:\n> On Wed, 29 Oct 2025 at 16:51, Christian Couder\n> wrote:\n> > On Wed, Oct 29, 2025 at 2:18 AM Bello Olamide wrote:\n\n> > > I also studied [3], [4] by Ayush Chandeker,] and [5] by John Cai to broaden my\n> > > understanding of the project.\n> >\n> > Are there some cases where strategies other than writing new accessors\n> > functions were used?\n>\n> Yes there were cases where the functions were adapted to use\n> exactly what it needs down the call chain rather than writing new\n> accessor functions.\n> An example is\n> https://public-inbox.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/#Z31csum-file.h\n> where the global variable `the_hash_algo` is replaced with an explicit parameter\n> `const struct git_hash_algo *algo` in low-level functions such as\n> `static struct hashfile *hashfd_internal()` and the call sites adapted\n> to use r->hash_algo\n> or the_repository->hash_algo in places where the subsystem has not gotten rid of\n> `the-repository`.\n>\n> This is also a strategy that can be used to replace global variables.\n\nYour answers are appreciated, but, just to be clear, I think it would\nbe nice if the answers to my questions like this one were part of a v2\nof your proposal. If I don't see a v2, I am less tempted to discuss\nthis further (which could hopefully help move the analysis forward and\nmake your proposal better).\n\nThanks.\n"},{"id":"529968","messageId":"20251030144934.9689-1-belkid98@gmail.com","threadId":"64403","inReplyTo":"CAD=f0L9anYu4LKWGDKrwzBBytMunJ3UjTehNN9m2DigG8yCNHA@mail.gmail.com","subject":"=?y?q?=5BOutreachy=5D=5BProposal=20v2=5D=3A=20Refactor=20in=20order=20to=20reduce=20Git=E2=80=99s=20global=20state?=","fromName":"Olamide Caleb Bello","fromEmail":"belkid98@gmail.com","sentAt":"2025-10-30T14:49:28Z","receivedAt":"2025-10-30T14:49:39Z","isPatch":false,"sender":{"key":"belkid98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/73387291?v=4"},"body":"Hello,\nThis is the second iteration on my proposal for the project\n\"Refactor in order to reduce Git’s global state\" for the 2025 Outreachy\nInternship program.\n\nThe changes from v1 includes answers to questions from Christian on other\nrefactoring strategies used asides writing new accessors, unfinished previous\nworks and the roadblocks encountered.\n\nPersonal Bio:\n===========\nFull Name: Bello Caleb Olamide\nEmail: belkid98@gmail.com\nPersonal Blog: https://cloobtech.hashnode.dev/\nGitHub: https://github.com/cloobtech\n\nAbout Me:\n=========\nI'm Bello Olamide. I am passionate about software engineering and\nI love to figure out things. I like participating in tech\nevents such as hackathons but this will be my first open source experience\nand I have relished the opportunity and experience so far.\nI love being part of a community that strive to achieve a goal and one that\nI found myself is a small albeit growing community that helps to guide and\nmentor younger boys find their way into the tech ecosystem. I have developed\nmy coding skill via various sources including personal learning, freelancing,\ncollaboration with other developers and from the ALX Software Engineering\nprogram.\n\nPast Experience with Git:\n===================\nI have been a Git user for sometime now majorly for collaborating with other\ndevelopers, tracking version changes to files and during this contribution\nstage, I have understood the ropes of how to send patches to Git.\n\nContributions to the Git Community:\n==========================\nI have been able to send some patches to the Git codebase with the guidance\nand direction of community members.\n\nMicroproject:\n==========\nLink: https://lore.kernel.org/git/cover.1761217100.git.belkid98@gmail.com/\nBranch: ob/gpg-interface-cleanup\nStatus: Merged to next\nCommit ID: ce6d041635\nDescription: strbuf_split*() to split a string into multiple strbufs\nis often a wrong API to use.\nA few uses of it have been removed by simplifying the code.\n\nProject Overview\n=============\nGit uses a single global `struct repository` object called `the_repository`\nwhich internal functions rely on to store, access and modify environment\nand configuration variables.\nWith this approach, multi-repository instances running in the same process\ncan lead to inconsistent behaviours and race conditions.\nBy refactoring the code to stop storing repository-scoped\nconfigurations in global variables in\n`environment.c file`, that is by moving the appropriate global\nvariables into localised state\nwithin the `struct repository` and `struct repo-settings`, the\ncodebase becomes more maintainable,\neasier to test and future work such as libifying Git becomes feasible.\n\nInternship Objectives and Plans\n========================\nThe project aims to identify repository scoped global variables in\n`environment.c` and related files that can be moved to local scope within\n`structrepository` and `struct repo-settings`, find an appropriate strategy\nto move them to local scope and implement the changes. This architectural\nimprovement will make the codebase more maintainable and enable better\nmulti-repository handling in the future.\n\nFrom a high level overview, environment.[ch] exposes some global\nvariables that reflect a per-repository state and examples of such include\ngit_work_tree_cfg, is_bare_repository_cfg, and core.* settings and functions\nwhich also depend on `the_repository` such as have_git_dir(),\nis_bare_repository().\n\nReview of Previous Work and Refactor Stategies:\n===============================================\nAfter a brief study of some related work done on the project,\nit is important to understand the purpose of the identified global variable\nand how it is used across the code base, observing how it relates with other\nsubsystems and moving it to the `struct repository` or `struct\nrepo-settings` if its use is repository specific, or specify an appropriate\ncontext based on its scopeand use this context in the accessor functions.\nFor example in [1], Patrick Steinhardt observes that `core.hooksPath`\nis repository specific and is stored in the global variable `git_hooks_path`.\nThe variable is then moved into local scope in the repo-settings\nstruct and a new accessor function `repo_settings_get_hooks_path()` is written\nand used to set the `hooks_path` of the repo specific struct which the path\nsubsystem reads from.\n\nSimilarly in [2], `core.sharedRepository` is tracked via the global variables\n`the_shared_repository ` and `need_shared_repository`. These are then\nmoved into the repo-settings struct, with new accessors functions\nwritten to modify them, and calls to the accessors in the path subsystem are\nthen modified to replace the old accessors which modify the global variables.\n\nThere were also cases where the functions were adapted to use exactly what it\nneeds down the call chain rather than writing new accessor functions.\nAn example is [3], where the global variable `the_hash_algo` is replaced with\nan explicit parameter `const struct git_hash_algo *algo` in low-level\nfunctions such as `static struct hashfile *hashfd_internal()` and the call\nsites adapted to use r->hash_algo or the_repository->hash_algo in places where\nthe subsystem has not gotten rid of `the_repository`.\nThis is also a strategy that can be used to replace global variables\n\n\nCompletion of Previous Unfinished Works\n---------------------------------------\nThere were also some pieces of work that were started but not finished which\nI plan to finish.\n* As an example, in [4], which attempts to move the `git_attributes_file`\n global variable to the `struct repository`.\n However because the global variable is used by the attributes subsystem and\n a single repository can have more than one set of attributes, that is\n the work-tree attributes and the index attributes, placing the variable into\n a repository instance and passing it around in the call chain will not be\n appropriate. Also most of the functions in the attributes subsystem pass the\n `index_state` as a parameter and not the repository. This is because an index\n knows its repository but a repository only knows its primary index.\n Therefore each repository for an index will need to be known from the index.\n\n As Junio pointed out in the discussion on the thread:\n \"As the attribute system is all about giving extra information on the\n paths that appear in the index and in the working tree, it may make\n sense for the API to go from the index state which is about the\n index and the working tree to access the attributes, rather than\n from the repository structure, which controls a lot wider concept\n and moving anything and everything there will easily and quickly\n make it a messy kitchen sink.\"\n\n So Given that the `index_state` struct has a repo member, we can move\n 'git_attributes_file' into the repo struct but access it through the\n `index_state`. By doing that we know the index truly owns the attributes.\n\n* There is also `is_bare_repository_cfg` as seen in [5].\n I have only skimmed through the discussions and patches to understand why it\n was not finished.\n But I will do an in depth study to understand why it was not completed and what\n it takes to finish it.\n\n\nProposed Project Execution Timeline\n===================================\n\n1. Study Code Base To Identify Suitable Candidates (Now - December 8, 2025):\n------------------------------------------------------------------------\n- The first step will be familiarising myself with the code base to\n understand how these global variables in environment.c are initialised,\n used and how they interact with other subsystems.\n\n2. Community Feedback Bonding ( December 9 - December 15, 2025):\n------------------------------------------------------------\n- Discuss environment variables with mentors and community members\n- Understand best refactoring approach based on feedback from mentors\n\n3. Review Existing Patch and Define Criteria (December 16 - January 9, 2026):\n-------------------------------------------------------------\n- Thoroughly examine the existing patch series submitted to the mailing\n list to understand;\n * What criteria makes a global variable a suitable candidate to be\n moved to the `struct repository` or `struct repo-settings`\n * What appropriate context it should be moved into based on its\n interactions with other subsystems.\n * If remaining a global variable is the best approach in its case.\n- This information can be gotten by paying attention to the discussions\n in the patches and also engaging with my mentors and the Git community.\n\nTo buttress the above points from my brief study of previous work,\nif the variable value is:\ni. meant to be different for different repositories, it is a candidate to move,\n if not then it is left as is, like the case of `local_repo_env[]`.\n\nii. used during early startup, it cannot be moved blindly but will need\n a closer inspection and refactoring of the startup code as is the case with\n `have_git_dir()` noted by Patrick and Shejialuo in [7].\n\nIts relationship with other subsystems is also a criteria to define\nsuch as the case of `git_attributes_file mentioned` above\n\n4. Implement Candidates and Submit PRs ( January 10 - February 28, 2026):\n--------------------------------------------------------------------------\n- With collaboration from mentors and the Git community, identify\n suitable candidates for relocation.\n- Relocate them into `struct repository`, `struct repo-settings` and\n other appropriate contexts.\n- Pass the repository parameter to accessor functions to replace the\n global dependence\n- Write new accessor functions if necessary else pass context directly to\n functions.\n- Modify accessor callers to reflect the new changes while ensuring\n all affected code paths works correctly\n- Update tests and documentations\n- Recursively submit patches for reviews, engaging in discussions and\n implement suggestions\n\n5. Final Report on Project (February 29 - March 6)\n--------------------------------\n- Document final report in my blog with details on my experience\n- Finalize any pending tasks or reviews on any submitted patch\n\nAvailability\n============\nI am currently not enrolled in any school or jobs, so I will be able to give\n30 hours a week or more to make the project a success.\n\nBlogging\n=========\nI have set up my blog where I will document my progress, insights,\nchallenges and experience weekly.\n\nPost Outreachy\n==============\nThe welcoming and patient atmosphere during this short contribution\nperiod with the Git\ncommunity has made me want to keep getting involved with the\ncommunity. I am committed to\ncontinuously contributing to Git and become a part of of the next set\nof contributors\nto champion the continuous development of Git.\n\nAppreciation\n============\nTo Junio and Christian, I really appreciate your guidance, patience\nand direction while\nreviewing and helping with my patches and to Usman for your inputs and to every\nmember of the Git community, I thank you all.\n\n\nReferences\n==========\n[1]: https://public-inbox.org/git/20250207-b4-pks-path-drop-the-repository-v2-14-13cad3c11b8a@pks.im/#Z31config.c\n[2]: https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-15-4e77f0313206@pks.im/\n[3]: https://public-inbox.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/#Z31csum-file.h\n[4]: https://lore.kernel.org/git/20250309153321.254844-1-ayu.chandekar@gmail.com/\n[5]: https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n[6]: https://lore.kernel.org/git/d0e2042b3061320fac8a8fdf9043c6ab4dbed5a2.1752882401.git.ayu.chandekar@gmail.com/\n[7]: https://lore.kernel.org/git/c82620a1f54ea6760bff204fd2b5fe5c2df1896c.1753804956.git.ayu.chandekar@gmail.com/\n"},{"id":"530025","messageId":"CAD=f0L8aMT+Qjgk4Gij1fVCVjKSyGfWS_tb6O54PT1=4KpbRJA@mail.gmail.com","threadId":"64403","inReplyTo":"CAP8UFD1v7yec7JwBGekJPvcq7kNJPuPTgWOVn+gBaw1+Sh2mdA@mail.gmail.com","subject":"Re: [Outreachy][Proposal]: Refactor in order to reduce Git’s global state","fromName":"Bello Olamide","fromEmail":"belkid98@gmail.com","sentAt":"2025-10-31T11:43:43Z","receivedAt":"2025-10-31T11:43:42Z","isPatch":false,"sender":{"key":"belkid98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/73387291?v=4"},"body":"On Thu, 30 Oct 2025 at 13:55, Christian Couder\n wrote:\n>\n> > Yes there were cases where the functions were adapted to use\n> > exactly what it needs down the call chain rather than writing new\n> > accessor functions.\n> > An example is\n> > https://public-inbox.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/#Z31csum-file.h\n> > where the global variable `the_hash_algo` is replaced with an explicit parameter\n> > `const struct git_hash_algo *algo` in low-level functions such as\n> > `static struct hashfile *hashfd_internal()` and the call sites adapted\n> > to use r->hash_algo\n> > or the_repository->hash_algo in places where the subsystem has not gotten rid of\n> > `the-repository`.\n> >\n> > This is also a strategy that can be used to replace global variables.\n>\n> Your answers are appreciated, but, just to be clear, I think it would\n> be nice if the answers to my questions like this one were part of a v2\n> of your proposal. If I don't see a v2, I am less tempted to discuss\n> this further (which could hopefully help move the analysis forward and\n> make your proposal better).\n>\n> Thanks.\n\nHello Christian\nThank you very much.\nI have added the answers to your question and submitted a v2 of the\nproposal.\n\nBello\n"},{"id":"530065","messageId":"CAD=f0L_dkfFam8fL24GV6r_yiVVARpMC_DH5Bem_yPeri1y7aA@mail.gmail.com","threadId":"64403","inReplyTo":"20251030144934.9689-1-belkid98@gmail.com","subject":"Re: [Outreachy][Proposal v2]: Refactor in order to reduce Git’s global state","fromName":"Bello Olamide","fromEmail":"belkid98@gmail.com","sentAt":"2025-11-01T19:13:49Z","receivedAt":"2025-11-01T19:13:48Z","isPatch":false,"sender":{"key":"belkid98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/73387291?v=4"},"body":"On Thu, 30 Oct 2025 at 15:49, Olamide Caleb Bello wrote:\n>\n> Hello,\n> This is the second iteration on my proposal for the project\n> \"Refactor in order to reduce Git’s global state\" for the 2025 Outreachy\n> Internship program.\n>\n> The changes from v1 includes answers to questions from Christian on other\n> refactoring strategies used asides writing new accessors, unfinished previous\n> works and the roadblocks encountered.\n>\n> Personal Bio:\n> ===========\n> Full Name: Bello Caleb Olamide\n> Email: belkid98@gmail.com\n> Personal Blog: https://cloobtech.hashnode.dev/\n> GitHub: https://github.com/cloobtech\n>\n> About Me:\n> =========\n> I'm Bello Olamide. I am passionate about software engineering and\n> I love to figure out things. I like participating in tech\n> events such as hackathons but this will be my first open source experience\n> and I have relished the opportunity and experience so far.\n> I love being part of a community that strive to achieve a goal and one that\n> I found myself is a small albeit growing community that helps to guide and\n> mentor younger boys find their way into the tech ecosystem. I have developed\n> my coding skill via various sources including personal learning, freelancing,\n> collaboration with other developers and from the ALX Software Engineering\n> program.\n>\n> Past Experience with Git:\n> ===================\n> I have been a Git user for sometime now majorly for collaborating with other\n> developers, tracking version changes to files and during this contribution\n> stage, I have understood the ropes of how to send patches to Git.\n>\n> Contributions to the Git Community:\n> ==========================\n> I have been able to send some patches to the Git codebase with the guidance\n> and direction of community members.\n>\n> Microproject:\n> ==========\n> Link: https://lore.kernel.org/git/cover.1761217100.git.belkid98@gmail.com/\n> Branch: ob/gpg-interface-cleanup\n> Status: Merged to next\n> Commit ID: ce6d041635\n> Description: strbuf_split*() to split a string into multiple strbufs\n> is often a wrong API to use.\n> A few uses of it have been removed by simplifying the code.\n>\n> Project Overview\n> =============\n> Git uses a single global `struct repository` object called `the_repository`\n> which internal functions rely on to store, access and modify environment\n> and configuration variables.\n> With this approach, multi-repository instances running in the same process\n> can lead to inconsistent behaviours and race conditions.\n> By refactoring the code to stop storing repository-scoped\n> configurations in global variables in\n> `environment.c file`, that is by moving the appropriate global\n> variables into localised state\n> within the `struct repository` and `struct repo-settings`, the\n> codebase becomes more maintainable,\n> easier to test and future work such as libifying Git becomes feasible.\n>\n> Internship Objectives and Plans\n> ========================\n> The project aims to identify repository scoped global variables in\n> `environment.c` and related files that can be moved to local scope within\n> `structrepository` and `struct repo-settings`, find an appropriate strategy\n> to move them to local scope and implement the changes. This architectural\n> improvement will make the codebase more maintainable and enable better\n> multi-repository handling in the future.\n>\n> From a high level overview, environment.[ch] exposes some global\n> variables that reflect a per-repository state and examples of such include\n> git_work_tree_cfg, is_bare_repository_cfg, and core.* settings and functions\n> which also depend on `the_repository` such as have_git_dir(),\n> is_bare_repository().\n>\n> Review of Previous Work and Refactor Stategies:\n> ===============================================\n> After a brief study of some related work done on the project,\n> it is important to understand the purpose of the identified global variable\n> and how it is used across the code base, observing how it relates with other\n> subsystems and moving it to the `struct repository` or `struct\n> repo-settings` if its use is repository specific, or specify an appropriate\n> context based on its scopeand use this context in the accessor functions.\n> For example in [1], Patrick Steinhardt observes that `core.hooksPath`\n> is repository specific and is stored in the global variable `git_hooks_path`.\n> The variable is then moved into local scope in the repo-settings\n> struct and a new accessor function `repo_settings_get_hooks_path()` is written\n> and used to set the `hooks_path` of the repo specific struct which the path\n> subsystem reads from.\n>\n> Similarly in [2], `core.sharedRepository` is tracked via the global variables\n> `the_shared_repository ` and `need_shared_repository`. These are then\n> moved into the repo-settings struct, with new accessors functions\n> written to modify them, and calls to the accessors in the path subsystem are\n> then modified to replace the old accessors which modify the global variables.\n>\n> There were also cases where the functions were adapted to use exactly what it\n> needs down the call chain rather than writing new accessor functions.\n> An example is [3], where the global variable `the_hash_algo` is replaced with\n> an explicit parameter `const struct git_hash_algo *algo` in low-level\n> functions such as `static struct hashfile *hashfd_internal()` and the call\n> sites adapted to use r->hash_algo or the_repository->hash_algo in places where\n> the subsystem has not gotten rid of `the_repository`.\n> This is also a strategy that can be used to replace global variables\n>\n>\n> Completion of Previous Unfinished Works\n> ---------------------------------------\n> There were also some pieces of work that were started but not finished which\n> I plan to finish.\n> * As an example, in [4], which attempts to move the `git_attributes_file`\n> global variable to the `struct repository`.\n> However because the global variable is used by the attributes subsystem and\n> a single repository can have more than one set of attributes, that is\n> the work-tree attributes and the index attributes, placing the variable into\n> a repository instance and passing it around in the call chain will not be\n> appropriate. Also most of the functions in the attributes subsystem pass the\n> `index_state` as a parameter and not the repository. This is because an index\n> knows its repository but a repository only knows its primary index.\n> Therefore each repository for an index will need to be known from the index.\n>\n> As Junio pointed out in the discussion on the thread:\n> \"As the attribute system is all about giving extra information on the\n> paths that appear in the index and in the working tree, it may make\n> sense for the API to go from the index state which is about the\n> index and the working tree to access the attributes, rather than\n> from the repository structure, which controls a lot wider concept\n> and moving anything and everything there will easily and quickly\n> make it a messy kitchen sink.\"\n>\n> So Given that the `index_state` struct has a repo member, we can move\n> 'git_attributes_file' into the repo struct but access it through the\n> `index_state`. By doing that we know the index truly owns the attributes.\n>\n> * There is also `is_bare_repository_cfg` as seen in [5].\n> I have only skimmed through the discussions and patches to understand why it\n> was not finished.\n> But I will do an in depth study to understand why it was not completed and what\n> it takes to finish it.\n>\n>\n> Proposed Project Execution Timeline\n> ===================================\n>\n> 1. Study Code Base To Identify Suitable Candidates (Now - December 8, 2025):\n> ------------------------------------------------------------------------\n> - The first step will be familiarising myself with the code base to\n> understand how these global variables in environment.c are initialised,\n> used and how they interact with other subsystems.\n>\n> 2. Community Feedback Bonding ( December 9 - December 15, 2025):\n> ------------------------------------------------------------\n> - Discuss environment variables with mentors and community members\n> - Understand best refactoring approach based on feedback from mentors\n>\n> 3. Review Existing Patch and Define Criteria (December 16 - January 9, 2026):\n> -------------------------------------------------------------\n> - Thoroughly examine the existing patch series submitted to the mailing\n> list to understand;\n> * What criteria makes a global variable a suitable candidate to be\n> moved to the `struct repository` or `struct repo-settings`\n> * What appropriate context it should be moved into based on its\n> interactions with other subsystems.\n> * If remaining a global variable is the best approach in its case.\n> - This information can be gotten by paying attention to the discussions\n> in the patches and also engaging with my mentors and the Git community.\n>\n> To buttress the above points from my brief study of previous work,\n> if the variable value is:\n> i. meant to be different for different repositories, it is a candidate to move,\n> if not then it is left as is, like the case of `local_repo_env[]`.\n>\n> ii. used during early startup, it cannot be moved blindly but will need\n> a closer inspection and refactoring of the startup code as is the case with\n> `have_git_dir()` noted by Patrick and Shejialuo in [7].\n>\n> Its relationship with other subsystems is also a criteria to define\n> such as the case of `git_attributes_file mentioned` above\n>\n> 4. Implement Candidates and Submit PRs ( January 10 - February 28, 2026):\n> --------------------------------------------------------------------------\n> - With collaboration from mentors and the Git community, identify\n> suitable candidates for relocation.\n> - Relocate them into `struct repository`, `struct repo-settings` and\n> other appropriate contexts.\n> - Pass the repository parameter to accessor functions to replace the\n> global dependence\n> - Write new accessor functions if necessary else pass context directly to\n> functions.\n> - Modify accessor callers to reflect the new changes while ensuring\n> all affected code paths works correctly\n> - Update tests and documentations\n> - Recursively submit patches for reviews, engaging in discussions and\n> implement suggestions\n>\n> 5. Final Report on Project (February 29 - March 6)\n> --------------------------------\n> - Document final report in my blog with details on my experience\n> - Finalize any pending tasks or reviews on any submitted patch\n>\n> Availability\n> ============\n> I am currently not enrolled in any school or jobs, so I will be able to give\n> 30 hours a week or more to make the project a success.\n>\n> Blogging\n> =========\n> I have set up my blog where I will document my progress, insights,\n> challenges and experience weekly.\n>\n> Post Outreachy\n> ==============\n> The welcoming and patient atmosphere during this short contribution\n> period with the Git\n> community has made me want to keep getting involved with the\n> community. I am committed to\n> continuously contributing to Git and become a part of of the next set\n> of contributors\n> to champion the continuous development of Git.\n>\n> Appreciation\n> ============\n> To Junio and Christian, I really appreciate your guidance, patience\n> and direction while\n> reviewing and helping with my patches and to Usman for your inputs and to every\n> member of the Git community, I thank you all.\n>\n>\n> References\n> ==========\n> [1]: https://public-inbox.org/git/20250207-b4-pks-path-drop-the-repository-v2-14-13cad3c11b8a@pks.im/#Z31config.c\n> [2]: https://public-inbox.org/git/20250206-b4-pks-path-drop-the-repository-v1-15-4e77f0313206@pks.im/\n> [3]: https://public-inbox.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/#Z31csum-file.h\n> [4]: https://lore.kernel.org/git/20250309153321.254844-1-ayu.chandekar@gmail.com/\n> [5]: https://public-inbox.org/git/pull.1826.git.git.1730926082.gitgitgadget@gmail.com/\n> [6]: https://lore.kernel.org/git/d0e2042b3061320fac8a8fdf9043c6ab4dbed5a2.1752882401.git.ayu.chandekar@gmail.com/\n> [7]: https://lore.kernel.org/git/c82620a1f54ea6760bff204fd2b5fe5c2df1896c.1753804956.git.ayu.chandekar@gmail.com/\n\nHello Christian\nPlease kindly refer to v3.\nI noticed the subject did not have the correct format on the mailing list.\nSomething went wrong when I was used git send-email\n\nThanks\n"}]}