2021-04-09 04:41:28 +08:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='git rm in sparse checked out working trees'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' "
|
|
|
|
mkdir -p sub/dir &&
|
|
|
|
touch a b c sub/d sub/dir/e &&
|
|
|
|
git add -A &&
|
|
|
|
git commit -m files &&
|
|
|
|
|
|
|
|
cat >sparse_error_header <<-EOF &&
|
2021-09-24 23:39:14 +08:00
|
|
|
The following paths and/or pathspecs matched paths that exist
|
|
|
|
outside of your sparse-checkout definition, so will not be
|
|
|
|
updated in the index:
|
2021-04-09 04:41:28 +08:00
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >sparse_hint <<-EOF &&
|
2021-09-24 23:39:14 +08:00
|
|
|
hint: If you intend to update such entries, try one of the following:
|
|
|
|
hint: * Use the --sparse option.
|
|
|
|
hint: * Disable or modify the sparsity rules.
|
2021-04-09 04:41:28 +08:00
|
|
|
hint: Disable this message with \"git config advice.updateSparsePath false\"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
echo b | cat sparse_error_header - >sparse_entry_b_error &&
|
|
|
|
cat sparse_entry_b_error sparse_hint >b_error_and_hint
|
|
|
|
"
|
|
|
|
|
|
|
|
for opt in "" -f --dry-run
|
|
|
|
do
|
|
|
|
test_expect_success "rm${opt:+ $opt} does not remove sparse entries" '
|
2022-04-22 10:32:18 +08:00
|
|
|
git sparse-checkout set --no-cone a &&
|
2021-04-09 04:41:28 +08:00
|
|
|
test_must_fail git rm $opt b 2>stderr &&
|
|
|
|
test_cmp b_error_and_hint stderr &&
|
|
|
|
git ls-files --error-unmatch b
|
|
|
|
'
|
|
|
|
done
|
|
|
|
|
|
|
|
test_expect_success 'recursive rm does not remove sparse entries' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set sub/dir &&
|
add, rm, mv: fix bug that prevents the update of non-sparse dirs
These three commands recently learned to avoid updating paths outside
the sparse checkout even if they are missing the SKIP_WORKTREE bit. This
is done using path_in_sparse_checkout(), which checks whether a given
path matches the current list of sparsity rules, similar to what
clear_ce_flags() does when we run "git sparse checkout init" or "git
sparse-checkout reapply". However, clear_ce_flags() uses a recursive
approach, applying the match results from parent directories on paths
that get the UNDECIDED result, whereas path_in_sparse_checkout() only
attempts to match the full path and immediately considers UNDECIDED as
NOT_MATCHED. This makes the function miss matches with leading
directories. For example, if the user has the sparsity patterns "!/a"
and "b/", add, rm, and mv will fail to update the path "a/b/c" and end
up displaying a warning about it being outside the sparse checkout even
though it isn't. This problem only occurs in full pattern mode as the
pattern matching functions never return UNDECIDED for cone mode.
To fix this, replicate the recursive behavior of clear_ce_flags() in
path_in_sparse_checkout(), falling back to the parent directory match
when a path gets the UNDECIDED result. (If this turns out to be too
expensive in some cases, we may want to later add some form of caching
to accelerate multiple queries within the same directory. This is not
implemented in this patch, though.) Also add two tests for each affected
command (add, rm, and mv) to check that they behave correctly with the
recursive pattern matching. The first test would previously fail without
this patch while the second already succeeded. It is added mostly to
make sure that we are not breaking the existing pattern matching for
directories that are really sparse, and also as a protection against any
future regressions.
Two other existing tests had to be changed as well: one test in t3602
checks that "git rm -r <dir>" won't remove sparse entries, but it didn't
allow the non-sparse entries inside <dir> to be removed. The other one,
in t7002, tested that "git mv" would correctly display a warning message
for sparse paths, but it accidentally expected the message to include
two non-sparse paths as well.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28 22:21:11 +08:00
|
|
|
git rm -r sub &&
|
2021-04-09 04:41:28 +08:00
|
|
|
git status --porcelain -uno >actual &&
|
2021-09-24 23:39:12 +08:00
|
|
|
cat >expected <<-\EOF &&
|
add, rm, mv: fix bug that prevents the update of non-sparse dirs
These three commands recently learned to avoid updating paths outside
the sparse checkout even if they are missing the SKIP_WORKTREE bit. This
is done using path_in_sparse_checkout(), which checks whether a given
path matches the current list of sparsity rules, similar to what
clear_ce_flags() does when we run "git sparse checkout init" or "git
sparse-checkout reapply". However, clear_ce_flags() uses a recursive
approach, applying the match results from parent directories on paths
that get the UNDECIDED result, whereas path_in_sparse_checkout() only
attempts to match the full path and immediately considers UNDECIDED as
NOT_MATCHED. This makes the function miss matches with leading
directories. For example, if the user has the sparsity patterns "!/a"
and "b/", add, rm, and mv will fail to update the path "a/b/c" and end
up displaying a warning about it being outside the sparse checkout even
though it isn't. This problem only occurs in full pattern mode as the
pattern matching functions never return UNDECIDED for cone mode.
To fix this, replicate the recursive behavior of clear_ce_flags() in
path_in_sparse_checkout(), falling back to the parent directory match
when a path gets the UNDECIDED result. (If this turns out to be too
expensive in some cases, we may want to later add some form of caching
to accelerate multiple queries within the same directory. This is not
implemented in this patch, though.) Also add two tests for each affected
command (add, rm, and mv) to check that they behave correctly with the
recursive pattern matching. The first test would previously fail without
this patch while the second already succeeded. It is added mostly to
make sure that we are not breaking the existing pattern matching for
directories that are really sparse, and also as a protection against any
future regressions.
Two other existing tests had to be changed as well: one test in t3602
checks that "git rm -r <dir>" won't remove sparse entries, but it didn't
allow the non-sparse entries inside <dir> to be removed. The other one,
in t7002, tested that "git mv" would correctly display a warning message
for sparse paths, but it accidentally expected the message to include
two non-sparse paths as well.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28 22:21:11 +08:00
|
|
|
D sub/dir/e
|
|
|
|
EOF
|
|
|
|
test_cmp expected actual &&
|
|
|
|
|
|
|
|
git rm --sparse -r sub &&
|
|
|
|
git status --porcelain -uno >actual2 &&
|
|
|
|
cat >expected2 <<-\EOF &&
|
2021-09-24 23:39:12 +08:00
|
|
|
D sub/d
|
|
|
|
D sub/dir/e
|
|
|
|
EOF
|
add, rm, mv: fix bug that prevents the update of non-sparse dirs
These three commands recently learned to avoid updating paths outside
the sparse checkout even if they are missing the SKIP_WORKTREE bit. This
is done using path_in_sparse_checkout(), which checks whether a given
path matches the current list of sparsity rules, similar to what
clear_ce_flags() does when we run "git sparse checkout init" or "git
sparse-checkout reapply". However, clear_ce_flags() uses a recursive
approach, applying the match results from parent directories on paths
that get the UNDECIDED result, whereas path_in_sparse_checkout() only
attempts to match the full path and immediately considers UNDECIDED as
NOT_MATCHED. This makes the function miss matches with leading
directories. For example, if the user has the sparsity patterns "!/a"
and "b/", add, rm, and mv will fail to update the path "a/b/c" and end
up displaying a warning about it being outside the sparse checkout even
though it isn't. This problem only occurs in full pattern mode as the
pattern matching functions never return UNDECIDED for cone mode.
To fix this, replicate the recursive behavior of clear_ce_flags() in
path_in_sparse_checkout(), falling back to the parent directory match
when a path gets the UNDECIDED result. (If this turns out to be too
expensive in some cases, we may want to later add some form of caching
to accelerate multiple queries within the same directory. This is not
implemented in this patch, though.) Also add two tests for each affected
command (add, rm, and mv) to check that they behave correctly with the
recursive pattern matching. The first test would previously fail without
this patch while the second already succeeded. It is added mostly to
make sure that we are not breaking the existing pattern matching for
directories that are really sparse, and also as a protection against any
future regressions.
Two other existing tests had to be changed as well: one test in t3602
checks that "git rm -r <dir>" won't remove sparse entries, but it didn't
allow the non-sparse entries inside <dir> to be removed. The other one,
in t7002, tested that "git mv" would correctly display a warning message
for sparse paths, but it accidentally expected the message to include
two non-sparse paths as well.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28 22:21:11 +08:00
|
|
|
test_cmp expected2 actual2
|
2021-04-09 04:41:28 +08:00
|
|
|
'
|
|
|
|
|
2021-09-24 23:39:11 +08:00
|
|
|
test_expect_success 'recursive rm --sparse removes sparse entries' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set "sub/dir" &&
|
|
|
|
git rm --sparse -r sub &&
|
|
|
|
git status --porcelain -uno >actual &&
|
|
|
|
cat >expected <<-\EOF &&
|
|
|
|
D sub/d
|
|
|
|
D sub/dir/e
|
|
|
|
EOF
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
|
|
|
|
2021-04-09 04:41:28 +08:00
|
|
|
test_expect_success 'rm obeys advice.updateSparsePath' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set a &&
|
|
|
|
test_must_fail git -c advice.updateSparsePath=false rm b 2>stderr &&
|
|
|
|
test_cmp sparse_entry_b_error stderr
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'do not advice about sparse entries when they do not match the pathspec' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set a &&
|
|
|
|
test_must_fail git rm nonexistent 2>stderr &&
|
|
|
|
grep "fatal: pathspec .nonexistent. did not match any files" stderr &&
|
|
|
|
! grep -F -f sparse_error_header stderr
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'do not warn about sparse entries when pathspec matches dense entries' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set a &&
|
|
|
|
git rm "[ba]" 2>stderr &&
|
|
|
|
test_must_be_empty stderr &&
|
|
|
|
git ls-files --error-unmatch b &&
|
|
|
|
test_must_fail git ls-files --error-unmatch a
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'do not warn about sparse entries with --ignore-unmatch' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set a &&
|
|
|
|
git rm --ignore-unmatch b 2>stderr &&
|
|
|
|
test_must_be_empty stderr &&
|
|
|
|
git ls-files --error-unmatch b
|
|
|
|
'
|
|
|
|
|
2021-09-24 23:39:12 +08:00
|
|
|
test_expect_success 'refuse to rm a non-skip-worktree path outside sparse cone' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout set a &&
|
|
|
|
git update-index --no-skip-worktree b &&
|
|
|
|
test_must_fail git rm b 2>stderr &&
|
|
|
|
test_cmp b_error_and_hint stderr &&
|
|
|
|
git rm --sparse b 2>stderr &&
|
|
|
|
test_must_be_empty stderr &&
|
|
|
|
test_path_is_missing b
|
|
|
|
'
|
|
|
|
|
add, rm, mv: fix bug that prevents the update of non-sparse dirs
These three commands recently learned to avoid updating paths outside
the sparse checkout even if they are missing the SKIP_WORKTREE bit. This
is done using path_in_sparse_checkout(), which checks whether a given
path matches the current list of sparsity rules, similar to what
clear_ce_flags() does when we run "git sparse checkout init" or "git
sparse-checkout reapply". However, clear_ce_flags() uses a recursive
approach, applying the match results from parent directories on paths
that get the UNDECIDED result, whereas path_in_sparse_checkout() only
attempts to match the full path and immediately considers UNDECIDED as
NOT_MATCHED. This makes the function miss matches with leading
directories. For example, if the user has the sparsity patterns "!/a"
and "b/", add, rm, and mv will fail to update the path "a/b/c" and end
up displaying a warning about it being outside the sparse checkout even
though it isn't. This problem only occurs in full pattern mode as the
pattern matching functions never return UNDECIDED for cone mode.
To fix this, replicate the recursive behavior of clear_ce_flags() in
path_in_sparse_checkout(), falling back to the parent directory match
when a path gets the UNDECIDED result. (If this turns out to be too
expensive in some cases, we may want to later add some form of caching
to accelerate multiple queries within the same directory. This is not
implemented in this patch, though.) Also add two tests for each affected
command (add, rm, and mv) to check that they behave correctly with the
recursive pattern matching. The first test would previously fail without
this patch while the second already succeeded. It is added mostly to
make sure that we are not breaking the existing pattern matching for
directories that are really sparse, and also as a protection against any
future regressions.
Two other existing tests had to be changed as well: one test in t3602
checks that "git rm -r <dir>" won't remove sparse entries, but it didn't
allow the non-sparse entries inside <dir> to be removed. The other one,
in t7002, tested that "git mv" would correctly display a warning message
for sparse paths, but it accidentally expected the message to include
two non-sparse paths as well.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28 22:21:11 +08:00
|
|
|
test_expect_success 'can remove files from non-sparse dir' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout disable &&
|
|
|
|
mkdir -p w x/y &&
|
|
|
|
test_commit w/f &&
|
|
|
|
test_commit x/y/f &&
|
|
|
|
|
2022-04-22 10:32:18 +08:00
|
|
|
git sparse-checkout set --no-cone w !/x y/ &&
|
add, rm, mv: fix bug that prevents the update of non-sparse dirs
These three commands recently learned to avoid updating paths outside
the sparse checkout even if they are missing the SKIP_WORKTREE bit. This
is done using path_in_sparse_checkout(), which checks whether a given
path matches the current list of sparsity rules, similar to what
clear_ce_flags() does when we run "git sparse checkout init" or "git
sparse-checkout reapply". However, clear_ce_flags() uses a recursive
approach, applying the match results from parent directories on paths
that get the UNDECIDED result, whereas path_in_sparse_checkout() only
attempts to match the full path and immediately considers UNDECIDED as
NOT_MATCHED. This makes the function miss matches with leading
directories. For example, if the user has the sparsity patterns "!/a"
and "b/", add, rm, and mv will fail to update the path "a/b/c" and end
up displaying a warning about it being outside the sparse checkout even
though it isn't. This problem only occurs in full pattern mode as the
pattern matching functions never return UNDECIDED for cone mode.
To fix this, replicate the recursive behavior of clear_ce_flags() in
path_in_sparse_checkout(), falling back to the parent directory match
when a path gets the UNDECIDED result. (If this turns out to be too
expensive in some cases, we may want to later add some form of caching
to accelerate multiple queries within the same directory. This is not
implemented in this patch, though.) Also add two tests for each affected
command (add, rm, and mv) to check that they behave correctly with the
recursive pattern matching. The first test would previously fail without
this patch while the second already succeeded. It is added mostly to
make sure that we are not breaking the existing pattern matching for
directories that are really sparse, and also as a protection against any
future regressions.
Two other existing tests had to be changed as well: one test in t3602
checks that "git rm -r <dir>" won't remove sparse entries, but it didn't
allow the non-sparse entries inside <dir> to be removed. The other one,
in t7002, tested that "git mv" would correctly display a warning message
for sparse paths, but it accidentally expected the message to include
two non-sparse paths as well.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28 22:21:11 +08:00
|
|
|
git rm w/f.t x/y/f.t 2>stderr &&
|
|
|
|
test_must_be_empty stderr
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'refuse to remove non-skip-worktree file from sparse dir' '
|
|
|
|
git reset --hard &&
|
|
|
|
git sparse-checkout disable &&
|
|
|
|
mkdir -p x/y/z &&
|
|
|
|
test_commit x/y/z/f &&
|
2022-04-22 10:32:18 +08:00
|
|
|
git sparse-checkout set --no-cone !/x y/ !x/y/z &&
|
add, rm, mv: fix bug that prevents the update of non-sparse dirs
These three commands recently learned to avoid updating paths outside
the sparse checkout even if they are missing the SKIP_WORKTREE bit. This
is done using path_in_sparse_checkout(), which checks whether a given
path matches the current list of sparsity rules, similar to what
clear_ce_flags() does when we run "git sparse checkout init" or "git
sparse-checkout reapply". However, clear_ce_flags() uses a recursive
approach, applying the match results from parent directories on paths
that get the UNDECIDED result, whereas path_in_sparse_checkout() only
attempts to match the full path and immediately considers UNDECIDED as
NOT_MATCHED. This makes the function miss matches with leading
directories. For example, if the user has the sparsity patterns "!/a"
and "b/", add, rm, and mv will fail to update the path "a/b/c" and end
up displaying a warning about it being outside the sparse checkout even
though it isn't. This problem only occurs in full pattern mode as the
pattern matching functions never return UNDECIDED for cone mode.
To fix this, replicate the recursive behavior of clear_ce_flags() in
path_in_sparse_checkout(), falling back to the parent directory match
when a path gets the UNDECIDED result. (If this turns out to be too
expensive in some cases, we may want to later add some form of caching
to accelerate multiple queries within the same directory. This is not
implemented in this patch, though.) Also add two tests for each affected
command (add, rm, and mv) to check that they behave correctly with the
recursive pattern matching. The first test would previously fail without
this patch while the second already succeeded. It is added mostly to
make sure that we are not breaking the existing pattern matching for
directories that are really sparse, and also as a protection against any
future regressions.
Two other existing tests had to be changed as well: one test in t3602
checks that "git rm -r <dir>" won't remove sparse entries, but it didn't
allow the non-sparse entries inside <dir> to be removed. The other one,
in t7002, tested that "git mv" would correctly display a warning message
for sparse paths, but it accidentally expected the message to include
two non-sparse paths as well.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-28 22:21:11 +08:00
|
|
|
|
|
|
|
git update-index --no-skip-worktree x/y/z/f.t &&
|
|
|
|
test_must_fail git rm x/y/z/f.t 2>stderr &&
|
|
|
|
echo x/y/z/f.t | cat sparse_error_header - sparse_hint >expect &&
|
|
|
|
test_cmp expect stderr
|
|
|
|
'
|
|
|
|
|
2021-04-09 04:41:28 +08:00
|
|
|
test_done
|