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