git/pathspec.c, branch v2.37.2

Merge branch 'jc/all-negative-pathspec'

2022-06-07T21:10:59Z

A git subcommand like "git add -p" spawns a separate git process while relaying its command line arguments. A pathspec with only negative elements was mistakenly passed with an empty string, which has been corrected. * jc/all-negative-pathspec: pathspec: correct an empty string used as a pathspec element

pathspec: correct an empty string used as a pathspec element

2022-05-29T22:42:18Z

Pathspecs with only negative elements did not work with some commands that pass the pathspec along to a subprocess. For instance, $ git add -p -- ':!*.txt' should add everything except for paths ending in ".txt", but it gets complaint from underlying "diff-index" and aborts. We used to error out when a pathspec with only negative elements in it, like the one in the above example. Later, 859b7f1d (pathspec: don't error out on all-exclusionary pathspec patterns, 2017-02-07) updated the logic to add an empty string as an extra element. The intention was to let the extra element to match everything and let the negative ones given by the user to subtract from it. At around the same time, we were migrating from "an empty string is a valid pathspec element that matches everything" to "either a dot or ":/" is used to match all, and an empty string is rejected", between d426430e (pathspec: warn on empty strings as pathspec, 2016-06-22) and 9e4e8a64 (pathspec: die on empty strings as pathspec, 2017-06-06). I think 9e4e8a64, which happened long after 859b7f1d happened, was not careful enough to turn the empty string 859b7f1d added to either a dot or ":/". A care should be taken as the definition of "everything" depends on subcommand. For the purpose of "add -p", adding a "." to add everything in the current directory is the right thing to do. But for some other commands, ":/" (i.e. really really everything, even things outside the current subdirectory) is the right choice. We would break commands in a big way if we get this wrong, so add a handful of test pieces to make sure the resulting code still excludes the paths that are expected and includes "everything" else. Signed-off-by: Junio C Hamano

add: skip tracked paths outside sparse-checkout cone

2021-09-28T17:31:02Z

When 'git add' adds a tracked file that is outside of the sparse-checkout cone, it checks the SKIP_WORKTREE bit to see if the file exists outside of the sparse-checkout cone. This is usually correct, except in the case of a merge conflict outside of the cone. Modify add_pathspec_matched_against_index() to be more careful about paths by checking the sparse-checkout patterns in addition to the SKIP_WORKTREE bit. This causes 'git add' to no longer allow files outside of the cone that removed the SKIP_WORKTREE bit due to a merge conflict. With only this change, users will only be able to add the file after adding the file to the sparse-checkout cone. A later change will allow users to force adding even though the file is outside of the sparse-checkout cone. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

pathspec: stop calling ensure_full_index

2021-07-29T19:36:34Z

The add_pathspec_matches_against_index() focuses on matching a pathspec to file entries in the index. This already works correctly for its only use: checking if untracked files exist in the index. The compatibility checks in t1092 already test that 'git add ' works for a directory outside of the sparse cone. That provides coverage for removing this guard. This finalizes our ability to run 'git add .' without expanding a sparse index to a full one. This is evidenced by an update to t1092 and by these performance numbers for p2000-sparse-operations.sh: Test HEAD~1 HEAD -------------------------------------------------------------------------------- 2000.10: git add . (full-index-v3) 0.37(0.28+0.07) 0.36(0.27+0.06) -2.7% 2000.11: git add . (full-index-v4) 0.33(0.26+0.06) 0.32(0.28+0.05) -3.0% 2000.12: git add . (sparse-index-v3) 0.57(0.53+0.07) 0.06(0.06+0.07) -89.5% 2000.13: git add . (sparse-index-v4) 0.57(0.53+0.07) 0.05(0.03+0.09) -91.2% While the ~90% improvement is shown by the test results, it is worth noting that expanding the sparse index was adding overhead in previous commits. Comparing to the full index case, we see the performance go from 0.33s to 0.05s, an 85% improvement. Reviewed-by: Elijah Newren Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'mt/add-rm-in-sparse-checkout'

2021-05-07T03:47:40Z

"git add" and "git rm" learned not to touch those paths that are outside of sparse checkout. * mt/add-rm-in-sparse-checkout: rm: honor sparse checkout patterns add: warn when asked to update SKIP_WORKTREE entries refresh_index(): add flag to ignore SKIP_WORKTREE entries pathspec: allow to ignore SKIP_WORKTREE entries on index matching add: make --chmod and --renormalize honor sparse checkouts t3705: add tests for `git add` in sparse checkouts add: include magic part of pathspec on --refresh error

Merge branch 'ds/sparse-index-protections'

2021-04-30T04:50:26Z

Builds on top of the sparse-index infrastructure to mark operations that are not ready to mark with the sparse index, causing them to fall back on fully-populated index that they always have worked with. * ds/sparse-index-protections: (47 commits) name-hash: use expand_to_path() sparse-index: expand_to_path() name-hash: don't add directories to name_hash revision: ensure full index resolve-undo: ensure full index read-cache: ensure full index pathspec: ensure full index merge-recursive: ensure full index entry: ensure full index dir: ensure full index update-index: ensure full index stash: ensure full index rm: ensure full index merge-index: ensure full index ls-files: ensure full index grep: ensure full index fsck: ensure full index difftool: ensure full index commit: ensure full index checkout: ensure full index ...

pathspec: ensure full index

2021-04-14T20:47:40Z

Before iterating over all cache entries, ensure that a sparse index is expanded to a full index to avoid unexpected behavior. Signed-off-by: Derrick Stolee Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano

*: remove 'const' qualifier for struct index_state

2021-04-14T20:46:00Z

Several methods specify that they take a 'struct index_state' pointer with the 'const' qualifier because they intend to only query the data, not change it. However, we will be introducing a step very low in the method stack that might modify a sparse-index to become a full index in the case that our queries venture inside a sparse-directory entry. This change only removes the 'const' qualifiers that are necessary for the following change which will actually modify the implementation of index_name_stage_pos(). Signed-off-by: Derrick Stolee Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano

add: warn when asked to update SKIP_WORKTREE entries

2021-04-08T21:18:03Z

`git add` already refrains from updating SKIP_WORKTREE entries, but it silently exits with zero code when it is asked to do so. Instead, let's warn the user and display a hint on how to update these entries. Note that we only warn the user whey they give a pathspec item that matches no eligible path for updating, but it does match one or more SKIP_WORKTREE entries. A warning was chosen over erroring out right away to reproduce the same behavior `add` already exhibits with ignored files. This also allow users to continue their workflow without having to invoke `add` again with only the eligible paths (as those will have already been added). Signed-off-by: Matheus Tavares Signed-off-by: Junio C Hamano

pathspec: allow to ignore SKIP_WORKTREE entries on index matching

2021-04-08T21:18:03Z

Add a new enum parameter to `add_pathspec_matches_against_index()` and `find_pathspecs_matching_against_index()`, allowing callers to specify whether these function should attempt to match SKIP_WORKTREE entries or not. This will be used in a future patch to make `git add` display a warning when it is asked to update SKIP_WORKTREE entries. Signed-off-by: Matheus Tavares Signed-off-by: Junio C Hamano