From: Srujith Poojary Date: Mon, 02 Nov 2026 11:25:28 GMT Subject: [Outreachy] Guidance on a possible pathspec contribution Message-ID: Hello Git community, I am currently working on my proposal for the December 2026 round of Outreachy for the project "Reduce Git's global state to enable Git's libification." Whilst looking through pathspec.c, I noticed that find_pathspecs_matching_skip_worktree() takes the index directly from the global repository via the_repository->index. This function finds pathspec matches for index entries that are either marked as skip-worktree or are outside the sparse checkout. Looking at matches_skip_worktree() (which calls this helper), I noticed that although the results are calculated and cached, no index is passed to the wrapper. The existing find_pathspecs_matching_against_index() API already accepts an explicit struct index_state *istate from its caller. However, it also takes an enum ps_skip_worktree_action as an argument, which currently has only two options. One option includes skip-worktree and out-of-sparse-checkout entries in matching, while the other ignores those entries. There is no option to match only those special entries. I am thinking of two potential solutions. Option 1: Continue using the specialised helper function, but pass the index_state explicitly. This would also require looking into passing the index through matches_skip_worktree() and its callers. Option 2: Look into adding another option to the existing ps_skip_worktree_action enum and updating the matching logic. This could allow us to match only skip-worktree or out-of-sparse-checkout entries using the existing matching API. Looking into where matches_skip_worktree() is used, I found calls in pathspec.c, builtin/add.c and builtin/rm.c. In builtin/rm.c, I also noticed several other uses of the_repository. Similarly, pathspec.c has other uses of the_repository, including in init_pathspec_item(). So I understand that changing this helper alone would only address one specific dependency and would not make the whole of pathspec.c or builtin/rm.c independent of global repository state. I have a few questions: - Do you think this is a useful and focused contribution to help with Git's libification? - Does passing the index explicitly through the specialised helper and wrapper make more sense, or should I look into modifying the existing matching API? - Is there any similar work already planned or being done? I haven't implemented either of these approaches or tested them yet. I wanted to get a good understanding of how the existing code works and check whether this would be a suitable contribution before proceeding. Thanks for your time. Kind regards, Srujith