[Outreachy] Guidance on a possible pathspec contribution

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