1
0
mirror of https://github.com/git/git.git synced 2024-09-27 08:41:11 +02:00
git/t/t1011-read-tree-sparse-checkout.sh

284 lines
6.9 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='sparse checkout tests
* (tag: removed, main) removed
| D sub/added
* (HEAD, tag: top) modified and added
| M init.t
| A sub/added
* (tag: init) init
A init.t
'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-read-tree.sh
test_expect_success 'setup' '
test_commit init &&
echo modified >>init.t &&
cat >expected <<-EOF &&
100644 $(git hash-object init.t) 0 init.t
100644 $EMPTY_BLOB 0 sub/added
100644 $EMPTY_BLOB 0 sub/addedtoo
100644 $EMPTY_BLOB 0 subsub/added
EOF
cat >expected.swt <<-\EOF &&
H init.t
H sub/added
H sub/addedtoo
H subsub/added
EOF
mkdir sub subsub &&
touch sub/added sub/addedtoo subsub/added &&
git add init.t sub/added sub/addedtoo subsub/added &&
git commit -m "modified and added" &&
git tag top &&
git rm sub/added &&
git commit -m removed &&
git tag removed &&
git checkout top &&
git ls-files --stage >result &&
test_cmp expected result
'
test_expect_success 'read-tree without .git/info/sparse-checkout' '
read_tree_u_must_succeed -m -u HEAD &&
git ls-files --stage >result &&
test_cmp expected result &&
git ls-files -t >result &&
test_cmp expected.swt result
'
test_expect_success 'read-tree with .git/info/sparse-checkout but disabled' '
echo >.git/info/sparse-checkout &&
read_tree_u_must_succeed -m -u HEAD &&
git ls-files -t >result &&
test_cmp expected.swt result &&
test -f init.t &&
test -f sub/added
'
test_expect_success 'read-tree --no-sparse-checkout with empty .git/info/sparse-checkout and enabled' '
git config core.sparsecheckout true &&
echo >.git/info/sparse-checkout &&
read_tree_u_must_succeed --no-sparse-checkout -m -u HEAD &&
git ls-files -t >result &&
test_cmp expected.swt result &&
test -f init.t &&
test -f sub/added
'
test_expect_success 'read-tree with empty .git/info/sparse-checkout' '
git config core.sparsecheckout true &&
echo >.git/info/sparse-checkout &&
read_tree_u_must_succeed -m -u HEAD &&
git ls-files --stage >result &&
test_cmp expected result &&
git ls-files -t >result &&
cat >expected.swt <<-\EOF &&
S init.t
S sub/added
S sub/addedtoo
S subsub/added
EOF
test_cmp expected.swt result &&
! test -f init.t &&
! test -f sub/added
'
test_expect_success 'match directories with trailing slash' '
cat >expected.swt-noinit <<-\EOF &&
S init.t
H sub/added
H sub/addedtoo
S subsub/added
EOF
echo sub/ > .git/info/sparse-checkout &&
read_tree_u_must_succeed -m -u HEAD &&
git ls-files -t > result &&
test_cmp expected.swt-noinit result &&
test ! -f init.t &&
test -f sub/added
'
unpack-trees: fix sparse checkout's "unable to match directories" Matching index entries against an excludes file currently has two problems. First, there's no function to do it. Code paths (like sparse checkout) that wanted to try it would iterate over index entries and for each index entry pass that path to excluded_from_list(). But that is not how excluded_from_list() works; one is supposed to feed in each ancester of a path before a given path to find out if it was excluded because of some parent or grandparent matching a bigsubdirectory/ pattern despite the path not matching any .gitignore pattern directly. Second, it's inefficient. The excludes mechanism is supposed to let us block off vast swaths of the filesystem as uninteresting; separately checking every index entry doesn't fit that model. Introduce a new function to take care of both these problems. This traverses the index in depth-first order (well, that's what order the index is in) to mark un-excluded entries. Maybe some day the in-core index format will be restructured to make this sort of operation easier. Or maybe we will want to try some binary search based thing. The interface is simple enough to allow all those things. Example: clear_ce_flags(the_index.cache, the_index.cache_nr, CE_CANDIDATE, CE_CLEARME, exclude_list); would clear the CE_CLEARME flag on all index entries with CE_CANDIDATE flag and not matched by exclude_list. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-26 19:17:46 +01:00
test_expect_success 'match directories without trailing slash' '
echo sub >.git/info/sparse-checkout &&
read_tree_u_must_succeed -m -u HEAD &&
git ls-files -t >result &&
unpack-trees: fix sparse checkout's "unable to match directories" Matching index entries against an excludes file currently has two problems. First, there's no function to do it. Code paths (like sparse checkout) that wanted to try it would iterate over index entries and for each index entry pass that path to excluded_from_list(). But that is not how excluded_from_list() works; one is supposed to feed in each ancester of a path before a given path to find out if it was excluded because of some parent or grandparent matching a bigsubdirectory/ pattern despite the path not matching any .gitignore pattern directly. Second, it's inefficient. The excludes mechanism is supposed to let us block off vast swaths of the filesystem as uninteresting; separately checking every index entry doesn't fit that model. Introduce a new function to take care of both these problems. This traverses the index in depth-first order (well, that's what order the index is in) to mark un-excluded entries. Maybe some day the in-core index format will be restructured to make this sort of operation easier. Or maybe we will want to try some binary search based thing. The interface is simple enough to allow all those things. Example: clear_ce_flags(the_index.cache, the_index.cache_nr, CE_CANDIDATE, CE_CLEARME, exclude_list); would clear the CE_CLEARME flag on all index entries with CE_CANDIDATE flag and not matched by exclude_list. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-26 19:17:46 +01:00
test_cmp expected.swt-noinit result &&
test ! -f init.t &&
test -f sub/added
'
test_expect_success 'match directories with negated patterns' '
cat >expected.swt-negation <<\EOF &&
S init.t
S sub/added
H sub/addedtoo
S subsub/added
EOF
cat >.git/info/sparse-checkout <<\EOF &&
sub
!sub/added
EOF
git read-tree -m -u HEAD &&
git ls-files -t >result &&
test_cmp expected.swt-negation result &&
test ! -f init.t &&
test ! -f sub/added &&
test -f sub/addedtoo
'
test_expect_success 'match directories with negated patterns (2)' '
cat >expected.swt-negation2 <<\EOF &&
H init.t
H sub/added
S sub/addedtoo
H subsub/added
EOF
cat >.git/info/sparse-checkout <<\EOF &&
/*
!sub
sub/added
EOF
git read-tree -m -u HEAD &&
git ls-files -t >result &&
test_cmp expected.swt-negation2 result &&
test -f init.t &&
test -f sub/added &&
test ! -f sub/addedtoo
'
unpack-trees: fix sparse checkout's "unable to match directories" Matching index entries against an excludes file currently has two problems. First, there's no function to do it. Code paths (like sparse checkout) that wanted to try it would iterate over index entries and for each index entry pass that path to excluded_from_list(). But that is not how excluded_from_list() works; one is supposed to feed in each ancester of a path before a given path to find out if it was excluded because of some parent or grandparent matching a bigsubdirectory/ pattern despite the path not matching any .gitignore pattern directly. Second, it's inefficient. The excludes mechanism is supposed to let us block off vast swaths of the filesystem as uninteresting; separately checking every index entry doesn't fit that model. Introduce a new function to take care of both these problems. This traverses the index in depth-first order (well, that's what order the index is in) to mark un-excluded entries. Maybe some day the in-core index format will be restructured to make this sort of operation easier. Or maybe we will want to try some binary search based thing. The interface is simple enough to allow all those things. Example: clear_ce_flags(the_index.cache, the_index.cache_nr, CE_CANDIDATE, CE_CLEARME, exclude_list); would clear the CE_CLEARME flag on all index entries with CE_CANDIDATE flag and not matched by exclude_list. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-26 19:17:46 +01:00
test_expect_success 'match directory pattern' '
echo "s?b" >.git/info/sparse-checkout &&
read_tree_u_must_succeed -m -u HEAD &&
unpack-trees: fix sparse checkout's "unable to match directories" Matching index entries against an excludes file currently has two problems. First, there's no function to do it. Code paths (like sparse checkout) that wanted to try it would iterate over index entries and for each index entry pass that path to excluded_from_list(). But that is not how excluded_from_list() works; one is supposed to feed in each ancester of a path before a given path to find out if it was excluded because of some parent or grandparent matching a bigsubdirectory/ pattern despite the path not matching any .gitignore pattern directly. Second, it's inefficient. The excludes mechanism is supposed to let us block off vast swaths of the filesystem as uninteresting; separately checking every index entry doesn't fit that model. Introduce a new function to take care of both these problems. This traverses the index in depth-first order (well, that's what order the index is in) to mark un-excluded entries. Maybe some day the in-core index format will be restructured to make this sort of operation easier. Or maybe we will want to try some binary search based thing. The interface is simple enough to allow all those things. Example: clear_ce_flags(the_index.cache, the_index.cache_nr, CE_CANDIDATE, CE_CLEARME, exclude_list); would clear the CE_CLEARME flag on all index entries with CE_CANDIDATE flag and not matched by exclude_list. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-26 19:17:46 +01:00
git ls-files -t >result &&
test_cmp expected.swt-noinit result &&
test ! -f init.t &&
test -f sub/added
'
test_expect_success 'checkout area changes' '
cat >expected.swt-nosub <<-\EOF &&
H init.t
S sub/added
S sub/addedtoo
S subsub/added
EOF
echo init.t >.git/info/sparse-checkout &&
read_tree_u_must_succeed -m -u HEAD &&
git ls-files -t >result &&
test_cmp expected.swt-nosub result &&
test -f init.t &&
test ! -f sub/added
'
test_expect_success 'read-tree updates worktree, absent case' '
echo sub/added >.git/info/sparse-checkout &&
git checkout -f top &&
read_tree_u_must_succeed -m -u HEAD^ &&
test ! -f init.t
'
test_expect_success 'read-tree updates worktree, dirty case' '
echo sub/added >.git/info/sparse-checkout &&
git checkout -f top &&
echo dirty >init.t &&
read_tree_u_must_succeed -m -u HEAD^ &&
grep -q dirty init.t &&
rm init.t
'
test_expect_success 'read-tree removes worktree, dirty case' '
echo init.t >.git/info/sparse-checkout &&
git checkout -f top &&
echo dirty >added &&
read_tree_u_must_succeed -m -u HEAD^ &&
grep -q dirty added
'
test_expect_success 'read-tree adds to worktree, absent case' '
echo init.t >.git/info/sparse-checkout &&
git checkout -f removed &&
read_tree_u_must_succeed -u -m HEAD^ &&
test ! -f sub/added
'
test_expect_success 'read-tree adds to worktree, dirty case' '
echo init.t >.git/info/sparse-checkout &&
git checkout -f removed &&
mkdir sub &&
echo dirty >sub/added &&
read_tree_u_must_succeed -u -m HEAD^ &&
grep -q dirty sub/added
'
test_expect_success 'index removal and worktree narrowing at the same time' '
echo init.t >.git/info/sparse-checkout &&
echo sub/added >>.git/info/sparse-checkout &&
git checkout -f top &&
echo init.t >.git/info/sparse-checkout &&
git checkout removed &&
git ls-files sub/added >result &&
test ! -f sub/added &&
test_must_be_empty result
'
test_expect_success 'read-tree --reset removes outside worktree' '
echo init.t >.git/info/sparse-checkout &&
git checkout -f top &&
git reset --hard removed &&
git ls-files sub/added >result &&
test_must_be_empty result
'
unpack-trees: failure to set SKIP_WORKTREE bits always just a warning Setting and clearing of the SKIP_WORKTREE bit is not only done when users run 'sparse-checkout'; other commands such as 'checkout' also run through unpack_trees() which has logic for handling this special bit. As such, we need to consider how they handle special cases. A couple comparison points should help explain the rationale for changing how unpack_trees() handles these bits: Ignoring sparse checkouts for a moment, if you are switching branches and have dirty changes, it is only considered an error that will prevent the branch switching from being successful if the dirty file happens to be one of the paths with different contents. SKIP_WORKTREE has always been considered advisory; for example, if rebase or merge need or even want to materialize a path as part of their work, they have always been allowed to do so regardless of the SKIP_WORKTREE setting. This has been used for unmerged paths, but it was often used for paths it wasn't needed just because it made the code simpler. It was a best-effort consideration, and when it materialized paths contrary to the SKIP_WORKTREE setting, it was never required to even print a warning message. In the past if you trying to run e.g. 'git checkout' and: 1) you had a path that was materialized and had some dirty changes 2) the path was listed in $GITDIR/info/sparse-checkout 3) this path did not different between the current and target branches then despite the comparison points above, the inability to set SKIP_WORKTREE was treated as a *hard* error that would abort the checkout operation. This is completely inconsistent with how SKIP_WORKTREE is handled elsewhere, and rather annoying for users as leaving the paths materialized in the working copy (with a simple warning) should present no problem at all. Downgrade any errors from inability to toggle the SKIP_WORKTREE bit to a warning and allow the operations to continue. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-27 01:49:00 +01:00
test_expect_success 'print warnings when some worktree updates disabled' '
echo sub >.git/info/sparse-checkout &&
git checkout -f init &&
mkdir sub &&
touch sub/added sub/addedtoo &&
unpack-trees: failure to set SKIP_WORKTREE bits always just a warning Setting and clearing of the SKIP_WORKTREE bit is not only done when users run 'sparse-checkout'; other commands such as 'checkout' also run through unpack_trees() which has logic for handling this special bit. As such, we need to consider how they handle special cases. A couple comparison points should help explain the rationale for changing how unpack_trees() handles these bits: Ignoring sparse checkouts for a moment, if you are switching branches and have dirty changes, it is only considered an error that will prevent the branch switching from being successful if the dirty file happens to be one of the paths with different contents. SKIP_WORKTREE has always been considered advisory; for example, if rebase or merge need or even want to materialize a path as part of their work, they have always been allowed to do so regardless of the SKIP_WORKTREE setting. This has been used for unmerged paths, but it was often used for paths it wasn't needed just because it made the code simpler. It was a best-effort consideration, and when it materialized paths contrary to the SKIP_WORKTREE setting, it was never required to even print a warning message. In the past if you trying to run e.g. 'git checkout' and: 1) you had a path that was materialized and had some dirty changes 2) the path was listed in $GITDIR/info/sparse-checkout 3) this path did not different between the current and target branches then despite the comparison points above, the inability to set SKIP_WORKTREE was treated as a *hard* error that would abort the checkout operation. This is completely inconsistent with how SKIP_WORKTREE is handled elsewhere, and rather annoying for users as leaving the paths materialized in the working copy (with a simple warning) should present no problem at all. Downgrade any errors from inability to toggle the SKIP_WORKTREE bit to a warning and allow the operations to continue. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-27 01:49:00 +01:00
# Use -q to suppress "Previous HEAD position" and "Head is now at" msgs
git checkout -q top 2>actual &&
cat >expected <<\EOF &&
unpack-trees: failure to set SKIP_WORKTREE bits always just a warning Setting and clearing of the SKIP_WORKTREE bit is not only done when users run 'sparse-checkout'; other commands such as 'checkout' also run through unpack_trees() which has logic for handling this special bit. As such, we need to consider how they handle special cases. A couple comparison points should help explain the rationale for changing how unpack_trees() handles these bits: Ignoring sparse checkouts for a moment, if you are switching branches and have dirty changes, it is only considered an error that will prevent the branch switching from being successful if the dirty file happens to be one of the paths with different contents. SKIP_WORKTREE has always been considered advisory; for example, if rebase or merge need or even want to materialize a path as part of their work, they have always been allowed to do so regardless of the SKIP_WORKTREE setting. This has been used for unmerged paths, but it was often used for paths it wasn't needed just because it made the code simpler. It was a best-effort consideration, and when it materialized paths contrary to the SKIP_WORKTREE setting, it was never required to even print a warning message. In the past if you trying to run e.g. 'git checkout' and: 1) you had a path that was materialized and had some dirty changes 2) the path was listed in $GITDIR/info/sparse-checkout 3) this path did not different between the current and target branches then despite the comparison points above, the inability to set SKIP_WORKTREE was treated as a *hard* error that would abort the checkout operation. This is completely inconsistent with how SKIP_WORKTREE is handled elsewhere, and rather annoying for users as leaving the paths materialized in the working copy (with a simple warning) should present no problem at all. Downgrade any errors from inability to toggle the SKIP_WORKTREE bit to a warning and allow the operations to continue. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-27 01:49:00 +01:00
warning: The following paths were already present and thus not updated despite sparse patterns:
sub/added
sub/addedtoo
unpack-trees: failure to set SKIP_WORKTREE bits always just a warning Setting and clearing of the SKIP_WORKTREE bit is not only done when users run 'sparse-checkout'; other commands such as 'checkout' also run through unpack_trees() which has logic for handling this special bit. As such, we need to consider how they handle special cases. A couple comparison points should help explain the rationale for changing how unpack_trees() handles these bits: Ignoring sparse checkouts for a moment, if you are switching branches and have dirty changes, it is only considered an error that will prevent the branch switching from being successful if the dirty file happens to be one of the paths with different contents. SKIP_WORKTREE has always been considered advisory; for example, if rebase or merge need or even want to materialize a path as part of their work, they have always been allowed to do so regardless of the SKIP_WORKTREE setting. This has been used for unmerged paths, but it was often used for paths it wasn't needed just because it made the code simpler. It was a best-effort consideration, and when it materialized paths contrary to the SKIP_WORKTREE setting, it was never required to even print a warning message. In the past if you trying to run e.g. 'git checkout' and: 1) you had a path that was materialized and had some dirty changes 2) the path was listed in $GITDIR/info/sparse-checkout 3) this path did not different between the current and target branches then despite the comparison points above, the inability to set SKIP_WORKTREE was treated as a *hard* error that would abort the checkout operation. This is completely inconsistent with how SKIP_WORKTREE is handled elsewhere, and rather annoying for users as leaving the paths materialized in the working copy (with a simple warning) should present no problem at all. Downgrade any errors from inability to toggle the SKIP_WORKTREE bit to a warning and allow the operations to continue. Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-27 01:49:00 +01:00
After fixing the above paths, you may want to run `git sparse-checkout reapply`.
EOF
test_cmp expected actual
'
test_expect_success 'checkout without --ignore-skip-worktree-bits' '
echo "*" >.git/info/sparse-checkout &&
git checkout -f top &&
test_path_is_file init.t &&
echo sub >.git/info/sparse-checkout &&
git checkout &&
echo modified >> sub/added &&
git checkout . &&
test_path_is_missing init.t &&
git diff --exit-code HEAD
'
test_expect_success 'checkout with --ignore-skip-worktree-bits' '
echo "*" >.git/info/sparse-checkout &&
git checkout -f top &&
test_path_is_file init.t &&
echo sub >.git/info/sparse-checkout &&
git checkout &&
echo modified >> sub/added &&
git checkout --ignore-skip-worktree-bits . &&
test_path_is_file init.t &&
git diff --exit-code HEAD
'
test_done