git-commit-vandalism/t/t6132-pathspec-exclude.sh

433 lines
9.4 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='test case exclude pathspec'
. ./test-lib.sh
test_expect_success 'setup' '
for p in file sub/file sub/sub/file sub/file2 sub/sub/sub/file sub2/file; do
if echo $p | grep /; then
mkdir -p $(dirname $p)
fi &&
: >$p &&
git add $p &&
git commit -m $p || return 1
done &&
git log --oneline --format=%s >actual &&
cat <<EOF >expect &&
sub2/file
sub/sub/sub/file
sub/file2
sub/sub/file
sub/file
file
EOF
test_cmp expect actual
'
test_expect_success 'exclude only pathspec uses default implicit pathspec' '
git log --oneline --format=%s -- . ":(exclude)sub" >expect &&
git log --oneline --format=%s -- ":(exclude)sub" >actual &&
test_cmp expect actual
'
test_expect_success 't_e_i() exclude sub' '
git log --oneline --format=%s -- . ":(exclude)sub" >actual &&
cat <<EOF >expect &&
sub2/file
file
EOF
test_cmp expect actual
'
test_expect_success 't_e_i() exclude sub/sub/file' '
git log --oneline --format=%s -- . ":(exclude)sub/sub/file" >actual &&
cat <<EOF >expect &&
sub2/file
sub/sub/sub/file
sub/file2
sub/file
file
EOF
test_cmp expect actual
'
test_expect_success 't_e_i() exclude sub using mnemonic' '
git log --oneline --format=%s -- . ":!sub" >actual &&
cat <<EOF >expect &&
sub2/file
file
EOF
test_cmp expect actual
'
test_expect_success 't_e_i() exclude :(icase)SUB' '
git log --oneline --format=%s -- . ":(exclude,icase)SUB" >actual &&
cat <<EOF >expect &&
sub2/file
file
EOF
test_cmp expect actual
'
test_expect_success 't_e_i() exclude sub2 from sub' '
(
cd sub &&
git log --oneline --format=%s -- :/ ":/!sub2" >actual &&
cat <<EOF >expect &&
sub/sub/sub/file
sub/file2
sub/sub/file
sub/file
file
EOF
test_cmp expect actual
)
'
test_expect_success 't_e_i() exclude sub/*file' '
git log --oneline --format=%s -- . ":(exclude)sub/*file" >actual &&
cat <<EOF >expect &&
sub2/file
sub/file2
file
EOF
test_cmp expect actual
'
test_expect_success 't_e_i() exclude :(glob)sub/*/file' '
git log --oneline --format=%s -- . ":(exclude,glob)sub/*/file" >actual &&
cat <<EOF >expect &&
sub2/file
sub/sub/sub/file
sub/file2
sub/file
file
EOF
test_cmp expect actual
'
test_expect_success 'm_p_d() exclude sub' '
git ls-files -- . ":(exclude)sub" >actual &&
cat <<EOF >expect &&
file
sub2/file
EOF
test_cmp expect actual
'
test_expect_success 'm_p_d() exclude sub/sub/file' '
git ls-files -- . ":(exclude)sub/sub/file" >actual &&
cat <<EOF >expect &&
file
sub/file
sub/file2
sub/sub/sub/file
sub2/file
EOF
test_cmp expect actual
'
test_expect_success 'm_p_d() exclude sub using mnemonic' '
git ls-files -- . ":!sub" >actual &&
cat <<EOF >expect &&
file
sub2/file
EOF
test_cmp expect actual
'
test_expect_success 'm_p_d() exclude :(icase)SUB' '
git ls-files -- . ":(exclude,icase)SUB" >actual &&
cat <<EOF >expect &&
file
sub2/file
EOF
test_cmp expect actual
'
test_expect_success 'm_p_d() exclude sub2 from sub' '
(
cd sub &&
git ls-files -- :/ ":/!sub2" >actual &&
cat <<EOF >expect &&
../file
file
file2
sub/file
sub/sub/file
EOF
test_cmp expect actual
)
'
test_expect_success 'm_p_d() exclude sub/*file' '
git ls-files -- . ":(exclude)sub/*file" >actual &&
cat <<EOF >expect &&
file
sub/file2
sub2/file
EOF
test_cmp expect actual
'
test_expect_success 'm_p_d() exclude :(glob)sub/*/file' '
git ls-files -- . ":(exclude,glob)sub/*/file" >actual &&
cat <<EOF >expect &&
file
sub/file
sub/file2
sub/sub/sub/file
sub2/file
EOF
test_cmp expect actual
'
test_expect_success 'multiple exclusions' '
git ls-files -- ":^*/file2" ":^sub2" >actual &&
cat <<-\EOF >expect &&
file
sub/file
sub/sub/file
sub/sub/sub/file
EOF
test_cmp expect actual
'
tree-walk.c: fix overoptimistic inclusion in :(exclude) matching tree_entry_interesting() is used for matching pathspec on a tree. The interesting thing about this function is that, because the tree entries are known to be sorted, this function can return more than just "yes, matched" and "no, not matched". It can also say "yes, this entry is matched and so is the remaining entries in the tree". This is where I made a mistake when matching exclude pathspec. For exclude pathspec, we do matching twice, one with positive patterns and one with negative ones, then a rule table is applied to determine the final "include or exclude" result. Note that "matched" does not necessarily mean include. For negative patterns, "matched" means exclude. This particular rule is too eager to include everything. Rule 8 says that "if all entries are positively matched" and the current entry is not negatively matched (i.e. not excluded), then all entries are positively matched and therefore included. But this is not true. If the _current_ entry is not negatively matched, it does not mean the next one will not be and we cannot conclude right away that all remaining entries are positively matched and can be included. Rules 8 and 18 are now updated to be less eager. We conclude that the current entry is positively matched and included. But we say nothing about remaining entries. tree_entry_interesting() will be called again for those entries where we will determine entries individually. Reported-by: Christophe Bliard <christophe.bliard@trux.info> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-04 06:28:51 +01:00
test_expect_success 't_e_i() exclude case #8' '
pathspec: correct an empty string used as a pathspec element 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 <gitster@pobox.com>
2022-05-30 00:39:51 +02:00
test_when_finished "rm -fr case8" &&
tree-walk.c: fix overoptimistic inclusion in :(exclude) matching tree_entry_interesting() is used for matching pathspec on a tree. The interesting thing about this function is that, because the tree entries are known to be sorted, this function can return more than just "yes, matched" and "no, not matched". It can also say "yes, this entry is matched and so is the remaining entries in the tree". This is where I made a mistake when matching exclude pathspec. For exclude pathspec, we do matching twice, one with positive patterns and one with negative ones, then a rule table is applied to determine the final "include or exclude" result. Note that "matched" does not necessarily mean include. For negative patterns, "matched" means exclude. This particular rule is too eager to include everything. Rule 8 says that "if all entries are positively matched" and the current entry is not negatively matched (i.e. not excluded), then all entries are positively matched and therefore included. But this is not true. If the _current_ entry is not negatively matched, it does not mean the next one will not be and we cannot conclude right away that all remaining entries are positively matched and can be included. Rules 8 and 18 are now updated to be less eager. We conclude that the current entry is positively matched and included. But we say nothing about remaining entries. tree_entry_interesting() will be called again for those entries where we will determine entries individually. Reported-by: Christophe Bliard <christophe.bliard@trux.info> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-04 06:28:51 +01:00
git init case8 &&
(
cd case8 &&
echo file >file1 &&
echo file >file2 &&
git add file1 file2 &&
git commit -m twofiles &&
git grep -l file HEAD :^file2 >actual &&
echo HEAD:file1 >expected &&
test_cmp expected actual &&
git grep -l file HEAD :^file1 >actual &&
echo HEAD:file2 >expected &&
test_cmp expected actual
)
'
dir: fix treatment of negated pathspecs do_match_pathspec() started life as match_pathspec_depth_1() and for correctness was only supposed to be called from match_pathspec_depth(). match_pathspec_depth() was later renamed to match_pathspec(), so the invariant we expect today is that do_match_pathspec() has no direct callers outside of match_pathspec(). Unfortunately, this intention was lost with the renames of the two functions, and additional calls to do_match_pathspec() were added in commits 75a6315f74 ("ls-files: add pathspec matching for submodules", 2016-10-07) and 89a1f4aaf7 ("dir: if our pathspec might match files under a dir, recurse into it", 2019-09-17). Of course, do_match_pathspec() had an important advantge over match_pathspec() -- match_pathspec() would hardcode flags to one of two values, and these new callers needed to pass some other value for flags. Also, although calling do_match_pathspec() directly was incorrect, there likely wasn't any difference in the observable end output, because the bug just meant that fill_diretory() would recurse into unneeded directories. Since subsequent does-this-path-match checks on individual paths under the directory would cause those extra paths to be filtered out, the only difference from using the wrong function was unnecessary computation. The second of those bad calls to do_match_pathspec() was involved -- via either direct movement or via copying+editing -- into a number of later refactors. See commits 777b420347 ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19), 8d92fb2927 ("dir: replace exponential algorithm with a linear one", 2020-04-01), and 95c11ecc73 ("Fix error-prone fill_directory() API; make it only return matches", 2020-04-01). The last of those introduced the usage of do_match_pathspec() on an individual file, and thus resulted in individual paths being returned that shouldn't be. The problem with calling do_match_pathspec() instead of match_pathspec() is that any negated patterns such as ':!unwanted_path` will be ignored. Add a new match_pathspec_with_flags() function to fulfill the needs of specifying special flags while still correctly checking negated patterns, add a big comment above do_match_pathspec() to prevent others from misusing it, and correct current callers of do_match_pathspec() to instead use either match_pathspec() or match_pathspec_with_flags(). One final note is that DO_MATCH_LEADING_PATHSPEC needs special consideration when working with DO_MATCH_EXCLUDE. The point of DO_MATCH_LEADING_PATHSPEC is that if we have a pathspec like */Makefile and we are checking a directory path like src/module/component that we want to consider it a match so that we recurse into the directory because it _might_ have a file named Makefile somewhere below. However, when we are using an exclusion pattern, i.e. we have a pathspec like :(exclude)*/Makefile we do NOT want to say that a directory path like src/module/component is a (negative) match. While there *might* be a file named 'Makefile' somewhere below that directory, there could also be other files and we cannot pre-emptively rule all the files under that directory out; we need to recurse and then check individual files. Adjust the DO_MATCH_LEADING_PATHSPEC logic to only get activated for positive pathspecs. Reported-by: John Millikin <jmillikin@stripe.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-05 20:23:48 +02:00
test_expect_success 'grep --untracked PATTERN' '
# This test is not an actual test of exclude patterns, rather it
# is here solely to ensure that if any tests are inserted, deleted, or
# changed above, that we still have untracked files with the expected
# contents for the NEXT two tests.
cat <<-\EOF >expect-grep &&
actual
expect
sub/actual
sub/expect
EOF
git grep -l --untracked file -- >actual-grep &&
test_cmp expect-grep actual-grep
'
test_expect_success 'grep --untracked PATTERN :(exclude)DIR' '
cat <<-\EOF >expect-grep &&
actual
expect
EOF
git grep -l --untracked file -- ":(exclude)sub" >actual-grep &&
test_cmp expect-grep actual-grep
'
test_expect_success 'grep --untracked PATTERN :(exclude)*FILE' '
cat <<-\EOF >expect-grep &&
actual
sub/actual
EOF
git grep -l --untracked file -- ":(exclude)*expect" >actual-grep &&
test_cmp expect-grep actual-grep
'
pathspec: correct an empty string used as a pathspec element 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 <gitster@pobox.com>
2022-05-30 00:39:51 +02:00
# Depending on the command, all negative pathspec needs to subtract
# either from the full tree, or from the current directory.
#
# The sample tree checked out at this point has:
# file
# sub/file
# sub/file2
# sub/sub/file
# sub/sub/sub/file
# sub2/file
#
# but there may also be some cruft that interferes with "git clean"
# and "git add" tests.
test_expect_success 'archive with all negative' '
git reset --hard &&
git clean -f &&
git -C sub archive --format=tar HEAD -- ":!sub/" >archive &&
"$TAR" tf archive >actual &&
cat >expect <<-\EOF &&
file
file2
EOF
test_cmp expect actual
'
test_expect_success 'add with all negative' '
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
git clean -f &&
test_when_finished "git reset --hard $H" &&
for path in file sub/file sub/sub/file sub2/file
do
echo smudge >>"$path" || return 1
done &&
git -C sub add -- ":!sub/" &&
git diff --name-only --no-renames --cached >actual &&
cat >expect <<-\EOF &&
file
sub/file
sub2/file
EOF
test_cmp expect actual &&
git diff --name-only --no-renames >actual &&
echo sub/sub/file >expect &&
test_cmp expect actual
'
test_lazy_prereq ADD_I_USE_BUILTIN_OR_PERL '
test_have_prereq ADD_I_USE_BUILTIN || test_have_prereq PERL
'
test_expect_success ADD_I_USE_BUILTIN_OR_PERL 'add -p with all negative' '
pathspec: correct an empty string used as a pathspec element 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 <gitster@pobox.com>
2022-05-30 00:39:51 +02:00
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
git clean -f &&
test_when_finished "git reset --hard $H" &&
for path in file sub/file sub/sub/file sub2/file
do
echo smudge >>"$path" || return 1
done &&
yes | git -C sub add -p -- ":!sub/" &&
git diff --name-only --no-renames --cached >actual &&
cat >expect <<-\EOF &&
file
sub/file
sub2/file
EOF
test_cmp expect actual &&
git diff --name-only --no-renames >actual &&
echo sub/sub/file >expect &&
test_cmp expect actual
'
test_expect_success 'clean with all negative' '
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
test_when_finished "git reset --hard $H && git clean -f" &&
git clean -f &&
for path in file9 sub/file9 sub/sub/file9 sub2/file9
do
echo cruft >"$path" || return 1
done &&
git -C sub clean -f -- ":!sub" &&
test_path_is_file file9 &&
test_path_is_missing sub/file9 &&
test_path_is_file sub/sub/file9 &&
test_path_is_file sub2/file9
'
test_expect_success 'commit with all negative' '
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
test_when_finished "git reset --hard $H" &&
for path in file sub/file sub/sub/file sub2/file
do
echo smudge >>"$path" || return 1
done &&
git -C sub commit -m sample -- ":!sub/" &&
git diff --name-only --no-renames HEAD^ HEAD >actual &&
cat >expect <<-\EOF &&
file
sub/file
sub2/file
EOF
test_cmp expect actual &&
git diff --name-only --no-renames HEAD >actual &&
echo sub/sub/file >expect &&
test_cmp expect actual
'
test_expect_success 'reset with all negative' '
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
test_when_finished "git reset --hard $H" &&
for path in file sub/file sub/sub/file sub2/file
do
echo smudge >>"$path" &&
git add "$path" || return 1
done &&
git -C sub reset --quiet -- ":!sub/" &&
git diff --name-only --no-renames --cached >actual &&
echo sub/sub/file >expect &&
test_cmp expect actual
'
test_expect_success 'grep with all negative' '
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
test_when_finished "git reset --hard $H" &&
for path in file sub/file sub/sub/file sub2/file
do
echo "needle $path" >>"$path" || return 1
done &&
git -C sub grep -h needle -- ":!sub/" >actual &&
cat >expect <<-\EOF &&
needle sub/file
EOF
test_cmp expect actual
'
test_expect_success 'ls-files with all negative' '
git reset --hard &&
git -C sub ls-files -- ":!sub/" >actual &&
cat >expect <<-\EOF &&
file
file2
EOF
test_cmp expect actual
'
test_expect_success 'rm with all negative' '
git reset --hard &&
test_when_finished "git reset --hard" &&
git -C sub rm -r --cached -- ":!sub/" >actual &&
git diff --name-only --no-renames --diff-filter=D --cached >actual &&
cat >expect <<-\EOF &&
sub/file
sub/file2
EOF
test_cmp expect actual
'
test_expect_success 'stash with all negative' '
H=$(git rev-parse HEAD) &&
git reset --hard $H &&
test_when_finished "git reset --hard $H" &&
for path in file sub/file sub/sub/file sub2/file
do
echo smudge >>"$path" || return 1
done &&
git -C sub stash push -m sample -- ":!sub/" &&
git diff --name-only --no-renames HEAD >actual &&
echo sub/sub/file >expect &&
test_cmp expect actual &&
git stash show --name-only >actual &&
cat >expect <<-\EOF &&
file
sub/file
sub2/file
EOF
test_cmp expect actual
'
test_done