{"thread":{"id":"66769","subject":"[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","startedAt":"2026-11-04T14:28:02Z","lastAt":"2026-11-05T00:01:49Z","messageCount":2,"participants":["Srujith Poojary","Usman Akinyemi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"557441","messageId":"CABh_KWjfH6iXNwFkzskpM_sijj5rgDiFEnqs57HJ7jmumcYTfg@mail.gmail.com","threadId":"66769","inReplyTo":null,"subject":"[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","fromName":"Srujith Poojary","fromEmail":"poojarysrujith@gmail.com","sentAt":"2026-11-04T14:28:02Z","receivedAt":"2026-11-04T14:28:02Z","isPatch":false,"sender":{"key":"poojarysrujith@gmail.com","avatar":null},"body":"Hello Git community,\n\nThank you for the guidance on sharing the proposal.\n\nI am resending my proposal inline so that reviewers can quote specific\nsections and provide feedback more easily.\n\nI would appreciate feedback on the technical scope, implementation\napproach, regression-testing strategy and feasibility of the proposed\nwork.\n\nProposal: Reduce Git's global state to enable Git's libification\n\n1. Introduction\n\nAs a BCA graduate, I have a good foundation of programming and have\nworked with some programming languages. I have practical experience\ndeveloping software projects and contributing to open source projects.\nWhile learning how to use Git and GitHub for version control and\nmanaging changes in my projects I became interested in using different\npublicly available open source repositories. This led me to become\ncurious about how Git works internally, How its source code is\nstructured, and how its developers keep such a huge project going.\n\nThis pushed me to look into the source code of Git. I learned about\nthe C concepts that are needed to understand the code such as\npointers, structures, functions and looking at how the different parts\ncode communicates with itself. I looked into the Git code related to\nrepositories and learned about concepts such as the_repository, struct\nrepository *repo, global state and explicit dependencies. This taught\nme that when contributing to a well established open source project\nthere is more to it than just writing code. You need to understand the\nexisting functionality, look at past changes and ensure that the code\nis tested properly.\n\nI made some contributions while preparing for this project. I made\nchanges to test scripts, test-path and safe integer arithmetic in\ndiff-delta. I worked on a submodule-related change involving\nrepository-specific commit abbreviations and made an updated patch\nseries for review. I gained practical experience of looking at\nexisting code, creating patches, testing and getting my code reviewed.\n\nWhen i got to know about this project is while watching videos on\nYouTube about Git and contributing to open source projects I\ndiscovered Outreachy. I submitted my initial application and looked\nthrough the list of projects available. I found the Git project,\n'Reduce Git's global state to enable Git's libification'. As I was\nalready interested in Git and GitHub and had begun learning about C\nprogramming, I decided to choose this project as it fit my interests.\nI began preparing for this project by completing the microproject,\nlooking at Git's source code, looking into past changes and\nresearching potential areas to contribute to for my main project.\n\nI am interested to involved with this Outreachy internship project for\nDecember 2026 as it will give me the opportunity to understand and\ncontribute to a key part of Git's internal design. I am interested in\nunderstanding how to replace implicit dependencies on global state by\npassing the required repository or index information explicitly. I\nwould like to learn how this can help make the code more testable,\nmaintainable and reusable.\n\nI hope to boost my C programming and problem solving skills during\nthis internship. I hope to make useful and thoroughly tested changes\nto Git. I am happy to look into the existing implementation, talk to\nmaintainers, learn from code reviews and improve my work using\ntechnical feedback and collaboration with community.\n\n2. Understanding the Project\n\n2.1 What is Git's global state?\n\nGlobal state is information stored in variables that can be accessed\nby different parts of a program. A global variable is declared outside\na function, so more than one function can access it. In Git, global\nvariables are used to store and access information such as repository\ndetails and environment settings.\n\nOne important example in Git is the_repository. It is a global pointer\nthat gives access to repository information through a struct\nrepository object. Different parts of Git can use this pointer to\nretrieve information about the repository currently in use. For\nexample, the_repository->index accesses that repository's index.\n\nThe problem is that a function can access a global variable directly\ninstead of receiving the information it needs through its arguments.\nThis creates a hidden dependency because the function relies on\ninformation that is not clear from its parameters. It can make the\nfunction harder to understand and test with different repository\ncontexts, and harder to reuse independently. Reducing these hidden\ndependencies is one reason Git is working to reduce its reliance on\nglobal state.\n\n2.2 What does libification mean?\n\nA software library refers to a set of code that can be used by other\nprograms to complete specific tasks. This means that we don’t need to\nfully implement something from scratch in our application.\n\nGit was originally designed as a command line tool. This means that\ndifferent sections of code can access the same information using\nglobal variables. Libification makes Git’s internal code more suitable\nto be used as a library by other applications. This can be an issue\nwhen trying to use Git’s internal code in other applications as it can\ncause issues due to relying on global variables.\n\nTo fix this we can pass the necessary information into the function\narguments. An example would be passing a struct repository pointer,\nsuch as struct repository *repo, as an argument so that the function\ncan access a specific repository. Or passing a struct index_state\npointer, such as struct index_state *istate so that the function can\nwork with a specific index. This makes it clear what the function\nrelies on and gives more control to developers.\n\nThis helps make Git’s code easier to understand, test, maintain and\nreuse in different scenarios. It can also help different sections of\nGit to work with different repository contexts. However, this is just\none part of the libification process and more may be needed to make\nGit’s internal code better suited to being a library.\n\n2.3 What has already been done?\n\nGit developers have been working to reduce global state. Two important\nstructures used to store repository-specific information are\nrepo_config_values and repo_settings.\n\nAn example I looked at was core.attributesFile. Previously this was\nstored in a global variable called git_attributes_file. When multiple\nrepositories are used in the same process, one repository's\nconfiguration could overwrite the value used for another repository.\nThis was refactored so that the value could be stored in the\nattributes_file member of repo_config_values.\n\nAnother example I looked at was core.hooksPath. Previously this was\nstored in a global variable called git_hooks_path. This could cause\nproblems when multiple repositories used different paths for their\nhooks in the same process. This was then refactored to store the value\nin struct repo_settings. A function called\nrepo_settings_get_hooks_path() was also introduced to load and cache\nthe value for the required repository. These examples helped me\nunderstand how Git uses various repository specific structures to\nreduce global state.\n\nIn Google Summer of Code 2026 there was a project called \"Refactoring\nin order to reduce Git's global state\". This aimed to reduce global\ndependencies by refactoring Git's environment handling and moving\nselected values into appropriate repository-specific structures,\nincluding repo_config_values. Some examples of these values include\nprotect_hfs, protect_ntfs, trust_executable_bit, ignore_case,\nexcludes_file and various program settings.\nThis work provides useful context for the current Outreachy project.\nThe earlier refactoring focused on reducing global state in Git's\nenvironment and configuration handling. The current project takes the\nbroader goal further by looking at how parts of Git can become\nsuitable for use as a library. My proposed pathspec investigation is a\npossible contribution to that ongoing effort, rather than a claim that\npathspec work was assigned or approved by the earlier GSoC mentors.\n\nIn the v2.56 release notes for Git there are several examples of\nchanges made to reduce global dependencies. These include functions in\ncopy.c being modified to take a repository argument, the use of\nrepository aware versions of the tempfile and lockfile APIs. Parts of\nthe refspec API were changed to remove their dependency on the global\nthe_repository by passing the hash algorithm explicitly. And\nrepository pointers are passed in ref and worktree related functions.\n\nOverall from looking at these changes, it seems that reducing global\nstate is a continuous process. As developers need to understand what\neach value is used for, and find the correct repository/structure to\nstore them in. Some of the information will need to be made explicit.\nThe December 2026 Outreachy project continues this larger effort by\nmaking Git's internal code more suitable for libification while\nmaintaining its existing behaviour.\n\n3. Previous Contributions and Preparation\n\n3.1 Contributions to Git\n\nWhile preparing for this project, I contributed to Git. I became\nfamiliar with reading code, finding issues, and making and testing\nchanges based on feedback from maintainers.\n\nContribution: Avoid pipes in the `t0001-init.sh` test script\nPull Request and mailing-list discussion: [PR\n#2260](https://github.com/gitgitgadget/git/pull/2260); [v2\nmailing-list discussion](https://lore.kernel.org/git/pull.2260.v2.git.1792666211685.gitgitgadget@gmail.com)\nStatus as of 4 November 2026: Integrated into `next` (also labelled\n`seen`). The GitHub PR remains open and is not marked as merged.\n\nContribution: Modernize test path checks in `t2030`\nPull Request and mailing-list discussion: [PR\n#2256](https://github.com/gitgitgadget/git/pull/2256); [v3\nmailing-list discussion](https://lore.kernel.org/git/pull.2256.v3.git.1792299943380.gitgitgadget@gmail.com)\nStatus as of 4 November 2026: Integrated into `seen`. The PR remains\nopen; the latest recorded status update available to me said it needed\nreview.\n\nContribution: Use safe integer arithmetic in `diff-delta`\nPull Request and mailing-list discussion: [PR\n#2276](https://github.com/gitgitgadget/git/pull/2276); [v9\nmailing-list discussion](https://lore.kernel.org/git/pull.2276.v9.git.1793120160248.gitgitgadget@gmail.com)\nStatus as of 4 November 2026: Integrated into `seen`. The PR remains\nopen; the latest recorded mailing-list status said it needed review.\n\nContribution: Use the submodule repository for commit abbreviations\nPull Request and mailing-list discussion: [PR\n#2288](https://github.com/gitgitgadget/git/pull/2288); [v5\nmailing-list discussion](https://lore.kernel.org/git/pull.2288.v5.git.1793763781129.gitgitgadget@gmail.com)\nStatus as of 4 November 2026: v5 was submitted to the Git mailing list\non 4 November 2026 and the PR is labelled `seen`. The GitHub PR\nremains open. The focused `t4041-diff-submodule-option.sh` test was\nreported as passing all 48 tests before the final squash.\n\nThese statuses distinguish integration into Git's review branches\n(next or seen) from a PR being merged into master. The GitHub PRs\nlisted above remain open as of this check.\n\nOverall, I became familiar with Git source code, the test suite,\nrepository handling, creating patches and the maintainer review\nprocess.\n\n3.2 Source-code preparation\n\nI investigated various areas of the Git source code, including\nrepository.c, repository.h, environment.c, alias.c, alias.h and\nbuiltin/help.c. I also read the Git v2.56.0 release notes to see what\nhad changed recently in the effort to reduce global state.\n\nI investigated how the_repository is used as a global pointer to the\nmain repository structure. I also looked at how functions receive\nrepository pointers (struct repository *repo) as arguments to access\nrepository-specific information.\n\nI looked at alias_lookup() in alias.c and examined how it uses\nthe_repository. This helped me understand that a function can receive\nsome information through its arguments while still relying on global\nstate for other information.\n\nI also investigated is_bare_repository() and the changes made in\ncommit 7ff3a5895b. The change separated the initial --bare\ncommand-line option from the repository-specific bare configuration.\nThis helped me understand why these different types of information\nneed to be stored separately.\n\nI became more familiar with commands such as git grep, sed, git log,\ngit show and git diff. I used them to locate functions, follow the\nflow of code and understand changes between commits. This made me more\ncomfortable investigating the codebase and understanding how global\ndependencies can be reduced.\n\nI also examined init_pathspec_item() in pathspec.c. This is a separate\narea from the skip-worktree matching helper: it uses the_repository\nfor repository-dependent path-prefix handling and error reporting.\nThis showed me that there may be other repository dependencies in\npathspec processing, but they need to be assessed individually. I have\nkept this as possible follow-up investigation rather than including it\nin the initial implementation scope.\n\n3.3 Understanding the project through case studies\n\nI investigated two examples in Git to understand how global state has\nbeen reduced.\n\nFor core.attributesFile, I found that the value was previously stored\nin the global variable git_attributes_file. It was later moved into\nthe attributes_file member of struct repo_config_values.\n\nFor core.hooksPath, the value was previously stored in the global\nvariable git_hooks_path. It was moved into struct repo_settings. A\nfunction called repo_settings_get_hooks_path() was also introduced to\nload and cache the value for the relevant repository.\n\nLooking at these changes helped me understand that reducing global\nstate involves deciding where information should be stored and how the\ncorrect repository should access it.\n\nI also looked at a more recent pathspec change, commit dd674df326\n(\"pathspec: use match for sparse-index expansion checks\"). This change\naddressed a heap-buffer-overflow involving prefixed wildcard pathspecs\nwith a sparse index. It changed the checks to use item.match, which\nincludes the path prefix, consistently instead of using item.original.\nThis is relevant prior work because it shows that pathspec changes\ninvolving prefixes and sparse indexes need careful compatibility and\nmemory-safety testing. My proposed helper investigation is separate\nfrom that change, and I will check for overlap rather than assume the\nwork is related or already covered.\n\n4. Problem Identification and Proposed Contribution\n\n4.1 Why investigate pathspec?\n\nA pathspec can be used by Git commands to determine which files or\npaths to target. It can be used to find a specific file, directory or\ngroup of files using patterns.\n\nPathspecs are used by several Git commands such as git add, git rm,\ngit grep and git diff.\n\nWhile investigating how pathspecs are implemented in Git, I noticed\nthat some of the pathspec-processing functions use the global pointer\nthe_repository to get information about the current repository. This\ncreates an implicit dependency.\n\nPathspec processing seems like a useful area to investigate. Making\ndependencies on specific repositories or indexes explicit can help\nreduce global state and make the code more reusable in different\nrepository contexts.\n\n4.2 Current technical observation\n\nIn my investigation on pathspec.c, I found that there is a function\ncalled find_pathspecs_matching_skip_worktree() that checks which\npathspecs match index entries marked with the skip-worktree flag or\nlocated outside the sparse-checkout area.\n\nThe function accesses the index via the_repository->index, but does\nnot accept it as a parameter. Instead, it uses the global pointer\nthe_repository. This has created an implicit dependency on the global\nrepository.\n\nOne possible improvement would be to pass a struct index_state *istate\nargument to the function. This would make the required index explicit\nand allow the function to use the index supplied by its caller.\n\nI investigated the inline wrapper for this function in pathspec.h.\nThis function is called matches_skip_worktree(), and calls\nfind_pathspecs_matching_skip_worktree(). The wrapper also caches the\nmatching results so they can be reused on subsequent calls.\n\nAny change to the helper will also require reviewing and updating the\nwrapper and its callers.\n\n4.3 Current call-site investigation\n\nI looked through the source code and found four call sites for\nmatches_skip_worktree(): one in pathspec.c, two in builtin/add.c, and\none in builtin/rm.c.\n\nEach of these callers will need to be considered when changing the\nhelper and wrapper interface. The caller must provide the appropriate\nindex state so that the function works with the intended repository.\n\nInterestingly, in builtin/rm.c, the cmd_rm() function has a struct\nrepository *repo argument already. However, the variable is marked as\nUNUSED. The surrounding code still refers to the_repository to get the\nindex. Therefore this caller will need further investigation to\ndetermine how to pass the correct index.\n\nThe changes should only be made to the relevant helper, wrapper and\ncallers. We should not make any assumptions that by updating these\ncall sites it will mean that the git add or git rm command is now free\nfrom global state.\n\n4.4 Proposed project objective\n\nI want to look into reducing a specific global repository/index\ndependency in Git's pathspec code.\n\nMy initial investigation focuses on\nfind_pathspecs_matching_skip_worktree(), which currently obtains the\nindex through the_repository->index instead of receiving the index it\nshould use as an argument.\n\nI will investigate two possible API approaches:\n\n1. Keep the specialised helper and add an explicit struct index_state\n*istate parameter. I would then review how this parameter should pass\nthrough the inline matches_skip_worktree() wrapper and its callers.\n2. Investigate whether the existing\nfind_pathspecs_matching_against_index() API could be extended with\nanother ps_skip_worktree_action option to support the required\nmatching behaviour.\n\nI will compare these approaches by looking at the existing API design,\nthe effect on callers, whether the required matching behaviour can be\nrepresented clearly, and the amount of change each approach\nintroduces. I will discuss the findings with mentors and maintainers\nbefore selecting the implementation.\n\nI will also review the four identified call sites and determine which\nindex state each one should use. If the selected design and Git's test\ninfrastructure allow it, I will add a targeted regression test to\ncheck that the helper uses the index supplied by its caller and that\nexisting sparse-checkout behaviour is preserved.\n\nAfter this initial investigation and focused change, I may look into\nwhether other pathspec functions could also receive repository or\nindex information explicitly. Any further work will depend on the\ntechnical findings and feedback from Git maintainers.\n\nThe aim is to reduce the reliance of selected parts of Git's pathspec\ncode on global state while preserving existing behaviour.\n\n4.5 Scope boundaries\n\nI intend to keep my initial work focused on the identified global\nindex dependency in find_pathspecs_matching_skip_worktree() and the\nAPI changes needed to address it.\n\n**What I will do initially:**\n\n- Investigate the helper's reliance on the_repository->index.\n- Compare the two API approaches described in Section 4.4 before\nselecting an implementation.\n- Review the inline wrapper and the four identified call sites, and\ndetermine the correct index state for each caller.\n- Investigate and, if feasible, add a focused regression test for the\nselected implementation.\n- Test the changes to ensure existing skip-worktree and\nsparse-checkout behaviour is preserved.\n\n**What I may investigate as follow-up work:**\n\n- Depending on the initial findings and feedback from Git maintainers,\ninvestigate init_pathspec_item() and selected parsing functions.\n- Look into other pathspec functions only where there is a clear\nrepository/index dependency and a technically justified benefit to\nmaking it explicit.\n- Discuss any wider changes with mentors and maintainers before\nexpanding the scope.\n\n**What I will not promise as part of the initial contribution:**\n\n- Rewrite the whole pathspec subsystem.\n- Remove all global variables from Git.\n- Guarantee that the_repository will be completely removed from\npathspec functions.\n- Claim that Git will become fully thread-safe as a result of this change.\n- Make unrelated changes outside the agreed pathspec scope.\n\nI will aim to make a focused and well-tested contribution while\npreserving existing functionality. Any follow-up work will depend on\ntechnical justification and maintainer guidance.\n\n5. Technical Implementation Plan\n\nI will begin this contribution by focusing on the identified\ndependency in the skip-worktree helper. The initial work will focus on\nmaking the index dependency explicit in the helper and updating the\nrelevant callers accordingly. Once this initial change has been\ncompleted, I will review the surrounding pathspec implementation to\nidentify whether any further work could help reduce dependencies on\nglobal repository state.\n\nPhase 1: Analyse the Current Implementation\n\n- Review the relevant pathspec implementation in pathspec.c.\n- Understand what find_pathspecs_matching_skip_worktree() currently\ndoes and how it works.\n- Understand how the repository index is represented using struct index_state.\n- Examine how skip-worktree entries are stored and used within the helper.\n- Understand how matches_skip_worktree() acts as a wrapper around the helper.\n- Identify the existing callers and investigate how they obtain and\nuse their index state.\n\nPhase 2: Compare the API Approaches and Select the Design\n\n- Investigate adding an explicit struct index_state *istate parameter\nto find_pathspecs_matching_skip_worktree().\n- Investigate whether the existing\nfind_pathspecs_matching_against_index() API could be extended with\nanother ps_skip_worktree_action option to provide the required\nbehaviour.\n- Compare both approaches in terms of API clarity, effect on existing\ncallers, maintainability and the size of the required change.\n- Discuss the findings with mentors and maintainers before selecting\nthe implementation.\n- For the selected approach, update the helper or API to use the\nappropriate index state rather than implicitly accessing\nthe_repository->index.\n- Ensure that the declaration, definition and inline wrapper are\nconsistent with the selected design.\n- Keep the initial change focused on the identified skip-worktree\nmatching dependency.\n\nPhase 3: Investigate and Update the Callers\n\n- Investigate the identified callers of the helper and its wrapper.\n- Review the callers in pathspec.c, builtin/add.c, and builtin/rm.c.\n- Identify which index state each caller should provide.\n- Pay particular attention to cmd_rm() and understand how it obtains\nand uses its index state.\n- Update the appropriate callers to pass the correct index state.\n- Review the surrounding code to ensure that the changes do not\nintroduce assumptions about which index is being used.\n\nPhase 4: Investigate Other Pathspec Dependencies\n\nOnce the initial helper change has been investigated, I will look into\nother pathspec functions to determine whether they have similar\ndependencies on global repository state.\n\n- Investigate init_pathspec_item() and understand how it uses\nrepository-related information.\n- Identify relevant dependencies involving repository context and\npath-prefix handling.\n- Examine selected pathspec parsing functions and identify their callers.\n- Consider whether explicit repository context could be introduced\nwhere there is a clear benefit.\n- Investigate potential compatibility issues before proposing further changes.\n- Discuss any wider changes with mentors and maintainers before\nexpanding the scope.\n\nThis investigation will remain conditional. I will not assume that the\nentire pathspec subsystem needs to be refactored.\n\nPhase 5: Make the Changes Clear and Easy to Review\n\n- Keep the initial implementation focused on the skip-worktree helper\nand its relevant callers.\n- Organise the changes into small, easy-to-understand patches where possible.\n- Follow Git's coding conventions and API design patterns.\n- Clearly explain why the changes are necessary.\n- Prepare the implementation for the testing and validation process\ndescribed in Section 6.\n- Refine the changes based on technical findings and feedback from maintainers.\n\nThe main contribution will be the initial change to the helper and its\nrelevant callers. Any further pathspec changes will depend on whether\nthey are technically justified and accepted by the Git community.\n\nThe implementation will be developed incrementally, with testing and\ncompatibility checks carried out as described in **Section 6: Testing\nand Validation Strategy**.\n\n6. Testing and Validation Strategy\n\nAn important part of my contribution will be testing to ensure that\nthe changes made do not break existing Git functionality.\n\nI will perform the following steps to test the changes:\n\n1. Analyse Existing Functionality\n\n- Analyse what find_pathspecs_matching_skip_worktree() does.\n- Understand how it reads the_repository->index.\n- See which functions call this helper and what behaviour they expect.\n- Record the expected behaviour before making changes.\n\n2. Add a Regression Test\n\n- Investigate whether a regression test using two separate struct\nindex_state instances can be added within Git's existing test\ninfrastructure.\n- If feasible, prepare two index states, with one containing a\nrelevant entry with CE_SKIP_WORKTREE set and the other without it.\n- If the test setup allows it, run the same pathspec against both indexes.\n- Also investigate paths located outside the sparse-checkout area,\nsince the helper checks these paths as well.\n- Check that the result depends on which index is passed to the helper\nrather than the default global index.\n- Where possible, verify that the regression test detects the original\nbehaviour and passes after my changes are made.\n\nI have researched this as a possible two-index test design, but have\nnot yet implemented or run this test. The next step is to confirm\nwhether Git's existing C unit-test infrastructure can construct and\nuse the required index states cleanly. If that is not practical, I\nwill discuss a suitable alternative regression test with maintainers.\n\n3. Compile and Run the Test\n\n- Make the agreed implementation changes.\n- If the regression test is feasible, compile it and run it.\n- Ensure that I follow Git's existing conventions for writing C unit\ntests, including the appropriate test location, registration, and\nsetup and cleanup.\n- Fix any issues caused by compilation errors or test failures.\n\n4. Run Relevant Compatibility Tests\n\nFor the initial helper/API change, I will:\n\n- Run relevant pathspec tests.\n- Run the sparse-checkout tests, including\nt3705-add-sparse-checkout.sh and t3602-rm-sparse-checkout.sh.\n- Check relevant git add and git rm behaviour.\n- Investigate compatibility with sparse-index and check for potential\nregressions.\n\nI will also check prefixed and wildcard pathspecs, particularly where\nthe selected change or its callers could affect those cases. If\nfollow-up changes to pathspec initialization or parsing are proposed,\nI will extend the compatibility checks to cover the relevant cases,\nsuch as PATHSPEC_NO_REPOSITORY, git diff --no-index, and path-prefix\nhandling. These follow-up checks will be selected according to the\nactual scope of any additional change.\n\n5. Test Changes After Review\n\n- Once changes have been made based on feedback from maintainers,\nre-run the relevant tests.\n- Ensure that the implementation does not break existing functionality.\n- Investigate any new errors and fix issues introduced by the changes.\n- Keep a record of the tests performed, their results, and any\nremaining limitations.\n\nDepending on the final implementation design and guidance from my\nmentors, I may adjust the testing approach. However, I want to ensure\nthat I have a relevant regression test and sufficient testing to\ndemonstrate that my changes work correctly without causing\nregressions.\n\n7. Thirteen-Week Work Plan\n\nI will be contributing for a total of 13 weeks, between 7th December\n2026 and 8th March 2027. I will be spending around 30 hours per week.\n\nI will approach this problem in small, manageable chunks. First, I\nwill look into the dependency I found relating to pathspec during my\npre-investigation. I will then discuss what exactly I am going to\nimplement with my mentors, taking into account the technical details,\nwhat work has already been done upstream, and what the community has\nto say.\n\nWeeks 1–2: Confirm the scope and finalize the design\n\nDiscuss what the scope of my work will be. This will include:\n\n- Reviewing the source-code investigation and technical details.\n- Talking with mentors to confirm whether pathspec is a suitable area\nfor my contribution.\n- Checking for upstream changes related to this area.\n- Reviewing the implementation of\nfind_pathspecs_matching_skip_worktree() and the functions that use it.\n- Comparing an explicit struct index_state *istate parameter for the\nspecialised helper with extending the existing\nfind_pathspecs_matching_against_index() API using another\nps_skip_worktree_action option.\n- Reviewing the effect of each approach on callers and\nmaintainability, then discussing the options with mentors and\nmaintainers before selecting the design.\n- Reviewing matches_skip_worktree() to understand how its return value is used.\n- Carefully reviewing cmd_rm() to determine how the repository and\nindex should be retrieved.\n- Discussing the minimal change and a feasible regression-testing\napproach with mentors.\n\n**Output:** A clear understanding of the agreed scope, the API design,\nand how the change will be implemented and tested.\n\nWeeks 3–4: Implement the agreed API change\n\n- Implement the API design selected after the initial investigation\nand discussion with mentors and maintainers.\n- Update the relevant function declaration, implementation and wrapper\nif needed.\n- Update call sites to ensure they use the correct index state.\n- Ensure that the existing skip-worktree matching behaviour remains unchanged.\n- Ensure that the code is compatible with the rest of the pathspec\nimplementation.\n- Build Git and perform initial checks.\n- Create a focused patch.\n\n**Output:** An initial implementation of the agreed API change, ready\nto be tested.\n\nWeek 5: Add and validate the focused regression test\n\n- Investigate whether the proposed two-index regression test can be\nadded within Git's existing test infrastructure.\n- If feasible, create the test using two indexes and the same\npathspec, and check that the behaviour depends on the index passed to\nthe helper.\n- Ensure that the cache entries and CE_SKIP_WORKTREE are being handled\ncorrectly.\n- Check the appropriate place for the unit test by looking at the\nexisting tests.\n- Build and run the test.\n- Where possible, ensure that the test detects the original behaviour\nand passes once the behaviour has been fixed.\n\n**Output:** A focused regression test, if the test setup is feasible,\nthat demonstrates the desired behaviour and helps prevent the hidden\ndependency from being reintroduced.\n\nWeeks 6–7: Compatibility testing and community review\n\n- Run pathspec and sparse-checkout tests.\n- Ensure that the changes have not affected relevant git add or git rm\nbehaviour.\n- Investigate compatibility with sparse-index.\n- Get feedback from mentors and the Git community on the\nimplementation and test results.\n- Make changes based on feedback.\n- Submit updated patches.\n\n**Output:** An initial change that has been reviewed and tested more\nthoroughly, with any compatibility issues identified.\n\nWeek 8: Evaluate further pathspec dependencies\n\n- Investigate any remaining repository dependencies.\n- Look into init_pathspec_item(), which uses the_repository to resolve\npath prefixes and report errors.\n- Consider whether there are other functions that need to take a\nrepository parameter.\n- If a larger change is desired, look into parse_pathspec() and\nparse_pathspec_file() and their call sites and dependencies.\n- Discuss possible next steps with mentors.\n\n**Output:** A clear technical understanding of whether any further\npathspec changes are needed.\n\nWeeks 9–10: Work on approved follow-up changes\n\n- If mentors agree that more work is appropriate, choose a small\nchange based on the investigation.\n- Look into the relevant call sites and decide how to pass repository\nor index information.\n- Ensure that behaviour remains the same for situations such as\nPATHSPEC_NO_REPOSITORY, git diff --no-index and path prefixes.\n- Implement the agreed change in small chunks.\n- Add or extend regression tests.\n- Build Git and run tests.\n- Submit focused patches.\n- If a larger parser change is not appropriate, use this time to\nimprove the initial contribution, address review feedback, or work on\nanother related task agreed with mentors.\n\n**Output:** A technically justified follow-up contribution, or an\nimproved initial contribution.\n\nWeek 11: Review and refine the implementation\n\n- Review all changes made.\n- Ensure that the implementation follows the agreed design and that\nrelevant repository-specific dependencies are explicit.\n- Check that the tests cover the intended behaviour and investigate edge cases.\n- Address further feedback.\n- Improve the organisation of patches, comments and documentation.\n- Run the relevant tests.\n\n**Output:** An improved patch series, with the technical reasoning,\nrelevant testing and any limitations documented clearly.\n\nWeeks 12–13: Final testing, documentation and handover\n\n- Run final focused test suites and any wider testing agreed with mentors.\n- Ensure that the changes do not break existing behaviour.\n- Address final feedback.\n- Review the final implementation and test results.\n- Document the design decisions, implementation and testing.\n- Summarise what has been done, which patches have been submitted or\nintegrated, and any remaining limitations.\n- Prepare a handover to Git maintainers, including potential future\nimprovements.\n\n**Output:** A validated and documented contribution, together with a\nsummary of completed work and possible next steps.\n\nWork-plan flexibility\n\nThe above plan is a suggested timeline. I may need to change it based\non technical issues, mentor guidance or feedback from the community.\nThe aim is to create a small, useful and well-tested change. Any\nfurther changes to pathspec or the parser will only be made if there\nis a technical reason and mentors agree.\n\nThe aim is not to remove all global dependencies in Git. The aim is to\nmake a meaningful contribution. The focus is on improving how\nrepository and index state are handled. If the initial pathspec change\noverlaps with existing work or is not considered appropriate, I will\nadjust the scope with mentors.\n\n8. Risks and Mitigation\n\nRisk 1: Existing global dependencies are more widespread than expected\n\nThe pathspec implementation may contain additional dependencies on\nthe_repository or other repository-related global variables beyond the\nhelper identified during the preliminary investigation.\n\n**Mitigation:**\n- I will review the relevant functions and their callers before making\nAPI changes.\n- I will check how repository and index state are accessed and used.\n- I will make changes incrementally, starting with the selected\nskip-worktree helper.\n- I will investigate any further dependencies before increasing the\nscope of the change.\n- I will not assume that a focused change has removed all global dependencies.\n\nRisk 2: Existing Git behavior may change accidentally\n\nChanges to how the helper accesses index state may cause unwanted\nchanges to current pathspec matching and skip-worktree behavior.\n\n**Mitigation:**\n- I will analyse the current behaviour and document it.\n- I will investigate and, if feasible, write a focused regression test\nusing two separate index states.\n- I will check that the outcome depends on the index passed to the\nhelper, rather than the default global index.\n- I will run focused tests covering relevant pathspec, git add and git\nrm operations.\n- I will check that existing behaviour, compatibility and error\nhandling are preserved.\n\nRisk 3: Sparse-checkout and sparse-index edge cases\n\nThe change may interact with current sparse-checkout behavior,\nskip-worktree entries, or sparse-index behavior.\n\n**Mitigation:**\n- I will test relevant skip-worktree entries and check that they\nbehave as expected.\n- I will test relevant pathspec forms, including prefixed and wildcard\npathspecs.\n- I will run the relevant sparse-checkout tests.\n- I will investigate sparse-index compatibility and look for possible\nregressions.\n- I will use sanitizers where appropriate.\n\nRisk 4: API changes may affect multiple callers\n\nThe helper may require changes to multiple callers. Some callers may\naccess repository or index state in different ways.\n\n**Mitigation:**\n- I will identify and review all known callers.\n- I will check which repository or index context each caller uses.\n- I will pay particular attention to cmd_rm() and how its repository\ncontext should be used.\n- I will compare the API options and discuss the most suitable\napproach with maintainers.\n- I will keep the resulting changes focused.\n\nRisk 5: Maintainer feedback or existing upstream work may change the\nproposed scope\n\nThe pathspec change is still open for feedback. There may be other\nchanges by maintainers or contributors that affect its suitability or\nscope.\n\n**Mitigation:**\n- Share the initial investigation and focused change early.\n- Ask for feedback before making wider changes to pathspec.\n- Check for upstream changes and possible overlap throughout the work.\n- Adjust the implementation based on feedback from maintainers.\n- If the scope is unsuitable or overlaps with existing work, discuss\nan alternative contribution with my mentors.\n\nRisk 6: The proposed regression-test approach may not fit Git's test\ninfrastructure\n\nThe two-index regression test may require a different setup or\nlocation based on Git's existing C unit-test conventions.\n\n**Mitigation:**\n- I will look at the existing C unit tests in Git.\n- I will study how index states, cache entries and CE_SKIP_WORKTREE are set up.\n- I will make sure the test is placed in the appropriate location,\nregistered and cleaned up correctly.\n- I will discuss the testing approach with maintainers if necessary.\n- I will build Git, compile the test and run it to verify the implementation.\n\n9. Communication and Review Strategy\n\nThroughout the internship, I will keep in communication with the Git community.\n\nMy strategy will include:\n\n- Using the public Git mailing list to communicate.\n- Asking clear and specific technical questions.\n- Submitting small, focused patches early to receive feedback.\n- Carefully reviewing feedback from maintainers and contributors and\nproviding responses.\n- Making necessary changes and resubmitting updated versions of the patches.\n- Explaining the technical reasoning behind the implementation and API choices.\n- Keeping patches concise, well-tested, and easy to review.\n- Clearly stating test results, including any failures or limitations.\n- Discussing any major changes to the proposal scope with my mentors.\n\nDuring my initial research, I emailed the Git community on 2 November\n2026 to ask whether my proposed pathspec contribution would be\nsuitable and to discuss the possible implementation approaches.\n\nThe discussion can be found here:\n\nhttps://gitlist.dev/t/66745\n\nI will use feedback from the Git community and my mentors to improve\nmy implementation approach. As the pathspec contribution has not yet\nbeen approved, I will not consider it confirmed until I receive\nguidance from maintainers.\n\n10. Expected Outcomes and Deliverables\n\nThe expected deliverables from my contribution include:\n\n- A clearer understanding of the chosen repository and index\ndependency within the pathspec implementation.\n- A comparison of the two API approaches: adding an explicit\nindex-state parameter to find_pathspecs_matching_skip_worktree(), or\nextending find_pathspecs_matching_against_index() with another\nps_skip_worktree_action option.\n- An initial patch implementing the API approach selected after\ntechnical investigation and discussion with maintainers, so that the\nrequired index state is explicit rather than obtained implicitly\nthrough the_repository.\n- Updating the relevant function declaration, definition, wrapper, and\ncallers to match the selected API.\n- Investigating and, if feasible, writing a targeted regression test\nto ensure that the helper uses the index provided, using two different\nindex states.\n- Testing relevant pathspec, sparse-checkout, git add, and git rm\nbehavior to verify that existing behavior is preserved.\n- Making additional repository-aware changes to the pathspec\nfunctions, assuming they are technically justified and agreed upon\nwith my mentors.\n- Preparing focused patches so that I can receive reviews and improve\nthem based on feedback from maintainers and contributors.\n- Recording the decisions made, the tests performed, and any remaining\nlimitations.\n\nThe exact deliverables will depend on the results of the technical\ninvestigation, the implementation approach, and feedback from the Git\ncommunity. The primary goal is to deliver a minimal, useful\ncontribution that is well-tested.\n\n11. Relevant Experience and Skills\n\nDuring preparation for this project, I have learned C programming\nfundamentals, explored Git's source code, and gained practical\nexperience working on Git.\n\nI have worked on the following:\n\n- Learning C programming, including functions, structures, pointers,\nfunction arguments, return values, and accessing structure members.\n- Understanding global variables, global state, and explicit\ndependencies, including how repository context can be passed to\nfunctions.\n- Exploring Git's source code, including repository.c, repository.h,\nenvironment.c, alias.c, and pathspec.c.\n- Understanding the_repository and struct repository *repo, as well as\ninvestigating how repository-specific state is accessed.\n- Studying previous refactoring work, including how\nis_bare_repository_cfg was split into separate responsibilities.\n- Exploring repository configuration and state management, including\ncore.attributesFile and core.hooksPath.\n- Using commands such as git grep, git log, git show, git diff, and\nsed to explore Git's source code, understand its history, and examine\nchanges.\n- Contributing to Git through changes involving test scripts, path\nchecks, safe integer arithmetic, and repository-aware commit\nabbreviations for submodules.\n- Creating and revising patches, responding to review feedback, and\nlearning how contributions are discussed within the Git community.\n- Exploring Git's testing framework and understanding how tests help\nverify existing behavior.\n\nThis preparation has helped me understand the importance of repository\ncontext, ownership of state, and careful refactoring in Git. Although\nI am still developing my C programming and Git internals knowledge, I\nhave gained practical experience exploring Git's codebase and\ncontributing changes. I would like to build on this foundation by\nmaking a focused contribution with appropriate testing during the\ninternship.\n\n12. Availability and Commitment\n\nI am available for this internship between 7 December 2026 and 8 March 2027.\n\nI can dedicate around 30 hours per week to the internship.\n\nDuring this period, I will:\n\n- Consistently dedicate time to the project.\n- Implement changes using an incremental approach.\n- Take time to understand the existing codebase.\n- Write tests and run them.\n- Engage in discussions and communication with my mentors and the Git community.\n- Take feedback into account and improve patches where needed.\n- Keep track of my progress and communicate any issues.\n\nI understand that contributing to an open-source project requires\ncontinuous learning, patience, and teamwork. I will work consistently\non my contributions, learn from feedback, and aim to make a useful\ncontribution to the Git project.\n\n13. References / Useful Links\n\nThe following links provide additional information about the Git\nproject and how to get involved. They also include examples of work I\nhave done previously and research I have carried out into the\ntechnical side of my proposed contribution.\n\nOfficial Git Information\n\n- Outreachy Project Selection for December 2026:\nhttps://www.outreachy.org/apply/project-selection/\n- Git Source Code: https://github.com/git/git\n- Git Documentation: https://git-scm.com/docs\n- Git Contribution Guidelines:\nhttps://github.com/git/git/blob/master/Documentation/SubmittingPatches\n- Git Coding Guidelines:\nhttps://github.com/git/git/blob/master/Documentation/CodingGuidelines\n- Git Mailing List: https://lore.kernel.org/git/\n- Git General Application Information:\nhttps://git.github.io/General-Application-Information/\n- Git Microproject Information:\nhttps://git.github.io/General-Microproject-Information/\n\nPrevious Contributions\n\nThese are examples of contributions I have made to the Git project,\nincluding work involving source code, test files, and preparing and\nrevising patches based on review feedback.\n\n- PR #2260 – t0001: avoid pipes in test scripts:\nhttps://github.com/gitgitgadget/git/pull/2260\n- PR #2256 – t2030: modernize test path checks:\nhttps://github.com/gitgitgadget/git/pull/2256\n- PR #2276 – diff-delta: use safe integer arithmetic:\nhttps://github.com/gitgitgadget/git/pull/2276\n- PR #2288 – t4041: use submodule repository for commit abbreviations:\nhttps://github.com/gitgitgadget/git/pull/2288\n\nMailing-list versions of these contributions:\n\n- PR #2260 v2: https://lore.kernel.org/git/pull.2260.v2.git.1792666211685.gitgitgadget@gmail.com\n- PR #2256 v3: https://lore.kernel.org/git/pull.2256.v3.git.1792299943380.gitgitgadget@gmail.com\n- PR #2276 v9: https://lore.kernel.org/git/pull.2276.v9.git.1793120160248.gitgitgadget@gmail.com\n- PR #2288 v5: https://lore.kernel.org/git/pull.2288.v5.git.1793763781129.gitgitgadget@gmail.com\n\nRelevant Source Code and Tests\n\n- pathspec.c: https://github.com/git/git/blob/master/pathspec.c\n- pathspec.h: https://github.com/git/git/blob/master/pathspec.h\n- builtin/add.c: https://github.com/git/git/blob/master/builtin/add.c\n- builtin/rm.c: https://github.com/git/git/blob/master/builtin/rm.c\n- Sparse-checkout tests for git add:\nhttps://github.com/git/git/blob/master/t/t3705-add-sparse-checkout.sh\n- Sparse-checkout tests for git rm:\nhttps://github.com/git/git/blob/master/t/t3602-rm-sparse-checkout.sh\n\nResearch into the Project\n\nDiscussion about the scope of the proposed pathspec contribution,\nincluding possible API approaches and whether related work is already\nplanned.\n\nhttps://gitlist.dev/t/66745 (2 November 2026)\n\nBackground on previous changes involving repository state and global\ndependencies.\n\n- Git v2.56.0 release notes:\nhttps://github.com/git/git/blob/master/Documentation/RelNotes/2.56.0.adoc\n- Commit 7ff3a5895b, which split the concerns of\nis_bare_repository_cfg: https://github.com/git/git/commit/7ff3a5895b\n- Commit dd674df326, which uses item.match consistently for\nsparse-index expansion checks and adds coverage for prefixed wildcard\npathspecs: https://github.com/git/git/commit/dd674df326\n- Git's official 2026 GSoC ideas page, including the project\n'Refactoring in order to reduce Git's global state':\nhttps://git.github.io/SoC-2026-Ideas/\n\n14. Conclusion\n\nReducing global state helps improve repository-specific information\nmanagement and makes dependencies clearer. It also supports Git's\nlonger-term goal of becoming libifiable.\n\nIn my preparation, I have explored Git's source code, investigated\nprevious refactoring efforts, and examined repository and index\ndependencies within the pathspec implementation.\n\nBased on my investigation, I would like to make a targeted improvement\nto the skip-worktree matching API. I will compare adding an explicit\nstruct index_state *istate parameter to\nfind_pathspecs_matching_skip_worktree() with extending the existing\nfind_pathspecs_matching_against_index() API. I will discuss the\nalternatives with maintainers and select the approach that provides\nthe clearest API and preserves existing behaviour.\n\nI will investigate a targeted regression test using two separate index\nstates to check that the helper uses the index passed to it and that\nexisting pathspec and skip-worktree behavior is preserved. The final\ntest design will depend on the available test infrastructure and the\nagreed implementation. Any further changes to pathspec will depend on\nthe technical findings and agreement with my mentors.\n\nThis work will require careful investigation, testing, and\ncommunication with the Git community. I am willing to learn from\nfeedback from reviewers and change my approach where necessary. I will\nalso make progress step by step.\n\nOverall, during my internship, I hope to improve my knowledge of Git\ninternals and C programming while contributing a focused and\nwell-tested improvement to the Git project.\n\nThank you for your time and guidance.\n\nRegards,\nSrujith\n\n"},{"id":"557516","messageId":"CAPSxiM_dPOWkRTWrVQcgqZELUET19ymokecj_T4VenM9EfHNSw@mail.gmail.com","threadId":"66769","inReplyTo":"CABh_KWjfH6iXNwFkzskpM_sijj5rgDiFEnqs57HJ7jmumcYTfg@mail.gmail.com","subject":"Re: [Outreachy][Proposal]: Reduce Git's global state to enable Git's libification[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2026-11-05T00:01:49Z","receivedAt":"2026-11-05T00:01:49Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Wed, Nov 4, 2026 at 3:28 PM Srujith Poojary <poojarysrujith@gmail.com> wrote:\n>\n> Hello Git community,\n>\n> Thank you for the guidance on sharing the proposal.\n>\n> I am resending my proposal inline so that reviewers can quote specific\n> sections and provide feedback more easily.\n>\n> I would appreciate feedback on the technical scope, implementation\n> approach, regression-testing strategy and feasibility of the proposed\n> work.\n>\n> Proposal: Reduce Git's global state to enable Git's libification\n>\n> 1. Introduction\n>\n> As a BCA graduate, I have a good foundation of programming and have\n> worked with some programming languages. I have practical experience\n> developing software projects and contributing to open source projects.\n> While learning how to use Git and GitHub for version control and\n> managing changes in my projects I became interested in using different\n> publicly available open source repositories. This led me to become\n> curious about how Git works internally, How its source code is\n> structured, and how its developers keep such a huge project going.\n>\n> This pushed me to look into the source code of Git. I learned about\n> the C concepts that are needed to understand the code such as\n> pointers, structures, functions and looking at how the different parts\n> code communicates with itself. I looked into the Git code related to\n> repositories and learned about concepts such as the_repository, struct\n> repository *repo, global state and explicit dependencies. This taught\n> me that when contributing to a well established open source project\n> there is more to it than just writing code. You need to understand the\n> existing functionality, look at past changes and ensure that the code\n> is tested properly.\n>\n> I made some contributions while preparing for this project. I made\n> changes to test scripts, test-path and safe integer arithmetic in\n> diff-delta. I worked on a submodule-related change involving\n> repository-specific commit abbreviations and made an updated patch\n> series for review. I gained practical experience of looking at\n> existing code, creating patches, testing and getting my code reviewed.\n>\n> When i got to know about this project is while watching videos on\n> YouTube about Git and contributing to open source projects I\n> discovered Outreachy. I submitted my initial application and looked\n> through the list of projects available. I found the Git project,\n> 'Reduce Git's global state to enable Git's libification'. As I was\n> already interested in Git and GitHub and had begun learning about C\n> programming, I decided to choose this project as it fit my interests.\n> I began preparing for this project by completing the microproject,\n> looking at Git's source code, looking into past changes and\n> researching potential areas to contribute to for my main project.\n>\n> I am interested to involved with this Outreachy internship project for\n\nYou might want to change this line to something like:\n\n\"\"I am interested in contributing to this Outreachy internship project\"\n\n> December 2026 as it will give me the opportunity to understand and\n> contribute to a key part of Git's internal design. I am interested in\n> understanding how to replace implicit dependencies on global state by\n> passing the required repository or index information explicitly. I\n> would like to learn how this can help make the code more testable,\n> maintainable and reusable.\n>\n> I hope to boost my C programming and problem solving skills during\n> this internship. I hope to make useful and thoroughly tested changes\n> to Git. I am happy to look into the existing implementation, talk to\n> maintainers, learn from code reviews and improve my work using\n> technical feedback and collaboration with community.\n>\n> 2. Understanding the Project\n>\n> 2.1 What is Git's global state?\n>\n> Global state is information stored in variables that can be accessed\n> by different parts of a program. A global variable is declared outside\n> a function, so more than one function can access it. In Git, global\n> variables are used to store and access information such as repository\n> details and environment settings.\n>\n> One important example in Git is the_repository. It is a global pointer\n> that gives access to repository information through a struct\n> repository object. Different parts of Git can use this pointer to\n> retrieve information about the repository currently in use. For\n> example, the_repository->index accesses that repository's index.\n>\n> The problem is that a function can access a global variable directly\n> instead of receiving the information it needs through its arguments.\n> This creates a hidden dependency because the function relies on\n> information that is not clear from its parameters. It can make the\n> function harder to understand and test with different repository\n> contexts, and harder to reuse independently. Reducing these hidden\n> dependencies is one reason Git is working to reduce its reliance on\n> global state.\n>\n> 2.2 What does libification mean?\n>\n> A software library refers to a set of code that can be used by other\n> programs to complete specific tasks. This means that we don’t need to\n> fully implement something from scratch in our application.\n>\n> Git was originally designed as a command line tool. This means that\n> different sections of code can access the same information using\n> global variables. Libification makes Git’s internal code more suitable\n> to be used as a library by other applications. This can be an issue\n> when trying to use Git’s internal code in other applications as it can\n> cause issues due to relying on global variables.\n>\n> To fix this we can pass the necessary information into the function\n> arguments. An example would be passing a struct repository pointer,\n> such as struct repository *repo, as an argument so that the function\n\nPassing a struct repository *repo as arguments to a function, while this\nis true, I believe passing the repo as an argument to the function is just\na means to an end which you already mentioned, as you said the main\ngoal is to remove the reliance of the codebase on the global \"the_repository\"\nand use the local \"repo\" instead.\n\n> can access a specific repository. Or passing a struct index_state\n> pointer, such as struct index_state *istate so that the function can\n> work with a specific index. This makes it clear what the function\n\n> **Output:** A technically justified follow-up contribution, or an\n> improved initial contribution.\n>\n> Week 11: Review and refine the implementation\n>\nI think you missed the blogging section.\n\nThanks for your interest in the Git project and do not forget to\nsubmit your application on the Outreachy website. I believe you can\nedit until the final deadline hour.\n\nUsman.\n\n"}]}