git/t/t6135-pathspec-with-attrs.sh

299 lines
6.7 KiB
Bash
Raw Permalink Normal View History

#!/bin/sh
test_description='test labels in pathspecs'
. ./test-lib.sh
test_expect_success 'setup a tree' '
cat <<-\EOF >expect &&
fileA
fileAB
fileAC
fileB
fileBC
fileC
fileNoLabel
fileSetLabel
fileUnsetLabel
fileValue
fileWrongLabel
sub/fileA
sub/fileAB
sub/fileAC
sub/fileB
sub/fileBC
sub/fileC
sub/fileNoLabel
sub/fileSetLabel
sub/fileUnsetLabel
sub/fileValue
sub/fileWrongLabel
EOF
mkdir sub &&
while read path
do
echo content >$path &&
git add $path || return 1
done <expect &&
git commit -m "initial commit" &&
git ls-files >actual &&
test_cmp expect actual
'
test_expect_success 'pathspec with no attr' '
test_must_fail git ls-files ":(attr:)"
'
test_expect_success 'pathspec with labels and non existent .gitattributes' '
git ls-files ":(attr:label)" >actual &&
test_must_be_empty actual
'
test_expect_success 'pathspec with labels and non existent .gitattributes (2)' '
test_must_fail git grep content HEAD -- ":(attr:label)"
'
test_expect_success 'setup .gitattributes' '
cat <<-\EOF >.gitattributes &&
fileA labelA
fileB labelB
fileC labelC
fileAB labelA labelB
fileAC labelA labelC
fileBC labelB labelC
fileUnsetLabel -label
fileSetLabel label
fileValue label=foo
fileWrongLabel label☺
EOF
dir: match "attr" pathspec magic with correct paths The match_pathspec_item() function takes "prefix" value, allowing a caller to chop off the common leading prefix of pathspec pattern strings from the path and only use the remainder of the path to match the pathspec patterns (after chopping the same leading prefix of them, of course). This "common leading prefix" optimization has two main features: * discard the entries in the in-core index that are outside of the common leading prefix; if you are doing "ls-files one/a one/b", we know all matches must be from "one/", so first the code discards all entries outside the "one/" directory from the in-core index. This allows us to work on a smaller dataset. * allow skipping the comparison of the leading bytes when matching pathspec with path. When "ls-files" finds the path "one/a/1" in the in-core index given "one/a" and "one/b" as the pathspec, knowing that common leading prefix "one/" was found lets the pathspec matchinery not to bother comparing "one/" part, and allows it to feed "a/1" down, as long as the pathspec element "one/a" gets corresponding adjustment to "a". When the "attr" pathspec magic is in effect, however, the current code breaks down. The attributes, other than the ones that are built-in and the ones that come from the $GIT_DIR/info/attributes file and the top-level .gitattributes file, are lazily read from the filesystem on-demand, as we encounter each path and ask if it matches the pathspec. For example, if you say "git ls-files "(attr:label)sub/" in a repository with a file "sub/file" that is given the 'label' attribute in "sub/.gitattributes": * The common prefix optimization finds that "sub/" is the common prefix and prunes the in-core index so that it has only entries inside that directory. This is desirable. * The code then walks the in-core index, finds "sub/file", and eventually asks do_match_pathspec() if it matches the given pathspec. * do_match_pathspec() calls match_pathspec_item() _after_ stripping the common prefix "sub/" from the path, giving it "file", plus the length of the common prefix (4-bytes), so that the pathspec element "(attr:label)sub/" can be treated as if it were "(attr:label)". The last one is what breaks the match in the current code, as the pathspec subsystem ends up asking the attribute subsystem to find the attribute attached to the path "file". We need to ask about the attributes on "sub/file" when calling match_pathspec_attrs(); this can be done by looking at "prefix" bytes before the beginning of "name", which is the same trick already used by another piece of the code in the same match_pathspec_item() function. Unfortunately this was not discovered so far because the code works with slightly different arguments, e.g. $ git ls-files "(attr:label)sub" $ git ls-files "(attr:label)sub/" "no/such/dir/" would have reported "sub/file" as a path with the 'label' attribute just fine, because neither would trigger the common prefix optimization. Reported-by: Matthew Hughes <mhughes@uw.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 15:35:33 -06:00
echo fileSetLabel label1 >sub/.gitattributes &&
git add .gitattributes sub/.gitattributes &&
git commit -m "add attributes"
'
test_expect_success 'check specific set attr' '
cat <<-\EOF >expect &&
fileSetLabel
sub/fileSetLabel
EOF
git ls-files ":(attr:label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check set attr with pathspec pattern' '
echo sub/fileSetLabel >expect &&
git ls-files ":(attr:label)sub" >actual &&
test_cmp expect actual &&
git ls-files ":(attr:label)sub/" >actual &&
test_cmp expect actual
'
test_expect_success 'check specific set attr in tree-ish' '
cat <<-\EOF >expect &&
HEAD:fileSetLabel
HEAD:sub/fileSetLabel
EOF
git grep -l content HEAD ":(attr:label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check specific set attr with pathspec pattern in tree-ish' '
echo HEAD:sub/fileSetLabel >expect &&
git grep -l content HEAD ":(attr:label)sub" >actual &&
test_cmp expect actual &&
git grep -l content HEAD ":(attr:label)sub/" >actual &&
test_cmp expect actual
'
test_expect_success 'check specific unset attr' '
cat <<-\EOF >expect &&
fileUnsetLabel
sub/fileUnsetLabel
EOF
git ls-files ":(attr:-label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check specific unset attr (2)' '
cat <<-\EOF >expect &&
HEAD:fileUnsetLabel
HEAD:sub/fileUnsetLabel
EOF
git grep -l content HEAD ":(attr:-label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check specific value attr' '
cat <<-\EOF >expect &&
fileValue
sub/fileValue
EOF
git ls-files ":(attr:label=foo)" >actual &&
test_cmp expect actual &&
git ls-files ":(attr:label=bar)" >actual &&
test_must_be_empty actual
'
test_expect_success 'check specific value attr (2)' '
cat <<-\EOF >expect &&
HEAD:fileValue
HEAD:sub/fileValue
EOF
git grep -l content HEAD ":(attr:label=foo)" >actual &&
test_cmp expect actual &&
test_must_fail git grep -l content HEAD ":(attr:label=bar)"
'
test_expect_success 'check unspecified attr' '
cat <<-\EOF >expect &&
.gitattributes
fileA
fileAB
fileAC
fileB
fileBC
fileC
fileNoLabel
fileWrongLabel
dir: match "attr" pathspec magic with correct paths The match_pathspec_item() function takes "prefix" value, allowing a caller to chop off the common leading prefix of pathspec pattern strings from the path and only use the remainder of the path to match the pathspec patterns (after chopping the same leading prefix of them, of course). This "common leading prefix" optimization has two main features: * discard the entries in the in-core index that are outside of the common leading prefix; if you are doing "ls-files one/a one/b", we know all matches must be from "one/", so first the code discards all entries outside the "one/" directory from the in-core index. This allows us to work on a smaller dataset. * allow skipping the comparison of the leading bytes when matching pathspec with path. When "ls-files" finds the path "one/a/1" in the in-core index given "one/a" and "one/b" as the pathspec, knowing that common leading prefix "one/" was found lets the pathspec matchinery not to bother comparing "one/" part, and allows it to feed "a/1" down, as long as the pathspec element "one/a" gets corresponding adjustment to "a". When the "attr" pathspec magic is in effect, however, the current code breaks down. The attributes, other than the ones that are built-in and the ones that come from the $GIT_DIR/info/attributes file and the top-level .gitattributes file, are lazily read from the filesystem on-demand, as we encounter each path and ask if it matches the pathspec. For example, if you say "git ls-files "(attr:label)sub/" in a repository with a file "sub/file" that is given the 'label' attribute in "sub/.gitattributes": * The common prefix optimization finds that "sub/" is the common prefix and prunes the in-core index so that it has only entries inside that directory. This is desirable. * The code then walks the in-core index, finds "sub/file", and eventually asks do_match_pathspec() if it matches the given pathspec. * do_match_pathspec() calls match_pathspec_item() _after_ stripping the common prefix "sub/" from the path, giving it "file", plus the length of the common prefix (4-bytes), so that the pathspec element "(attr:label)sub/" can be treated as if it were "(attr:label)". The last one is what breaks the match in the current code, as the pathspec subsystem ends up asking the attribute subsystem to find the attribute attached to the path "file". We need to ask about the attributes on "sub/file" when calling match_pathspec_attrs(); this can be done by looking at "prefix" bytes before the beginning of "name", which is the same trick already used by another piece of the code in the same match_pathspec_item() function. Unfortunately this was not discovered so far because the code works with slightly different arguments, e.g. $ git ls-files "(attr:label)sub" $ git ls-files "(attr:label)sub/" "no/such/dir/" would have reported "sub/file" as a path with the 'label' attribute just fine, because neither would trigger the common prefix optimization. Reported-by: Matthew Hughes <mhughes@uw.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 15:35:33 -06:00
sub/.gitattributes
sub/fileA
sub/fileAB
sub/fileAC
sub/fileB
sub/fileBC
sub/fileC
sub/fileNoLabel
sub/fileWrongLabel
EOF
git ls-files ":(attr:!label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check unspecified attr (2)' '
cat <<-\EOF >expect &&
HEAD:.gitattributes
HEAD:fileA
HEAD:fileAB
HEAD:fileAC
HEAD:fileB
HEAD:fileBC
HEAD:fileC
HEAD:fileNoLabel
HEAD:fileWrongLabel
dir: match "attr" pathspec magic with correct paths The match_pathspec_item() function takes "prefix" value, allowing a caller to chop off the common leading prefix of pathspec pattern strings from the path and only use the remainder of the path to match the pathspec patterns (after chopping the same leading prefix of them, of course). This "common leading prefix" optimization has two main features: * discard the entries in the in-core index that are outside of the common leading prefix; if you are doing "ls-files one/a one/b", we know all matches must be from "one/", so first the code discards all entries outside the "one/" directory from the in-core index. This allows us to work on a smaller dataset. * allow skipping the comparison of the leading bytes when matching pathspec with path. When "ls-files" finds the path "one/a/1" in the in-core index given "one/a" and "one/b" as the pathspec, knowing that common leading prefix "one/" was found lets the pathspec matchinery not to bother comparing "one/" part, and allows it to feed "a/1" down, as long as the pathspec element "one/a" gets corresponding adjustment to "a". When the "attr" pathspec magic is in effect, however, the current code breaks down. The attributes, other than the ones that are built-in and the ones that come from the $GIT_DIR/info/attributes file and the top-level .gitattributes file, are lazily read from the filesystem on-demand, as we encounter each path and ask if it matches the pathspec. For example, if you say "git ls-files "(attr:label)sub/" in a repository with a file "sub/file" that is given the 'label' attribute in "sub/.gitattributes": * The common prefix optimization finds that "sub/" is the common prefix and prunes the in-core index so that it has only entries inside that directory. This is desirable. * The code then walks the in-core index, finds "sub/file", and eventually asks do_match_pathspec() if it matches the given pathspec. * do_match_pathspec() calls match_pathspec_item() _after_ stripping the common prefix "sub/" from the path, giving it "file", plus the length of the common prefix (4-bytes), so that the pathspec element "(attr:label)sub/" can be treated as if it were "(attr:label)". The last one is what breaks the match in the current code, as the pathspec subsystem ends up asking the attribute subsystem to find the attribute attached to the path "file". We need to ask about the attributes on "sub/file" when calling match_pathspec_attrs(); this can be done by looking at "prefix" bytes before the beginning of "name", which is the same trick already used by another piece of the code in the same match_pathspec_item() function. Unfortunately this was not discovered so far because the code works with slightly different arguments, e.g. $ git ls-files "(attr:label)sub" $ git ls-files "(attr:label)sub/" "no/such/dir/" would have reported "sub/file" as a path with the 'label' attribute just fine, because neither would trigger the common prefix optimization. Reported-by: Matthew Hughes <mhughes@uw.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 15:35:33 -06:00
HEAD:sub/.gitattributes
HEAD:sub/fileA
HEAD:sub/fileAB
HEAD:sub/fileAC
HEAD:sub/fileB
HEAD:sub/fileBC
HEAD:sub/fileC
HEAD:sub/fileNoLabel
HEAD:sub/fileWrongLabel
EOF
git grep -l ^ HEAD ":(attr:!label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check multiple unspecified attr' '
cat <<-\EOF >expect &&
.gitattributes
fileC
fileNoLabel
fileWrongLabel
dir: match "attr" pathspec magic with correct paths The match_pathspec_item() function takes "prefix" value, allowing a caller to chop off the common leading prefix of pathspec pattern strings from the path and only use the remainder of the path to match the pathspec patterns (after chopping the same leading prefix of them, of course). This "common leading prefix" optimization has two main features: * discard the entries in the in-core index that are outside of the common leading prefix; if you are doing "ls-files one/a one/b", we know all matches must be from "one/", so first the code discards all entries outside the "one/" directory from the in-core index. This allows us to work on a smaller dataset. * allow skipping the comparison of the leading bytes when matching pathspec with path. When "ls-files" finds the path "one/a/1" in the in-core index given "one/a" and "one/b" as the pathspec, knowing that common leading prefix "one/" was found lets the pathspec matchinery not to bother comparing "one/" part, and allows it to feed "a/1" down, as long as the pathspec element "one/a" gets corresponding adjustment to "a". When the "attr" pathspec magic is in effect, however, the current code breaks down. The attributes, other than the ones that are built-in and the ones that come from the $GIT_DIR/info/attributes file and the top-level .gitattributes file, are lazily read from the filesystem on-demand, as we encounter each path and ask if it matches the pathspec. For example, if you say "git ls-files "(attr:label)sub/" in a repository with a file "sub/file" that is given the 'label' attribute in "sub/.gitattributes": * The common prefix optimization finds that "sub/" is the common prefix and prunes the in-core index so that it has only entries inside that directory. This is desirable. * The code then walks the in-core index, finds "sub/file", and eventually asks do_match_pathspec() if it matches the given pathspec. * do_match_pathspec() calls match_pathspec_item() _after_ stripping the common prefix "sub/" from the path, giving it "file", plus the length of the common prefix (4-bytes), so that the pathspec element "(attr:label)sub/" can be treated as if it were "(attr:label)". The last one is what breaks the match in the current code, as the pathspec subsystem ends up asking the attribute subsystem to find the attribute attached to the path "file". We need to ask about the attributes on "sub/file" when calling match_pathspec_attrs(); this can be done by looking at "prefix" bytes before the beginning of "name", which is the same trick already used by another piece of the code in the same match_pathspec_item() function. Unfortunately this was not discovered so far because the code works with slightly different arguments, e.g. $ git ls-files "(attr:label)sub" $ git ls-files "(attr:label)sub/" "no/such/dir/" would have reported "sub/file" as a path with the 'label' attribute just fine, because neither would trigger the common prefix optimization. Reported-by: Matthew Hughes <mhughes@uw.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 15:35:33 -06:00
sub/.gitattributes
sub/fileC
sub/fileNoLabel
sub/fileWrongLabel
EOF
git ls-files ":(attr:!labelB !labelA !label)" >actual &&
test_cmp expect actual
'
test_expect_success 'check label with more labels but excluded path' '
cat <<-\EOF >expect &&
fileAB
fileB
fileBC
EOF
git ls-files ":(attr:labelB)" ":(exclude)sub/" >actual &&
test_cmp expect actual
'
test_expect_success 'check label excluding other labels' '
cat <<-\EOF >expect &&
fileAB
fileB
fileBC
sub/fileAB
sub/fileB
EOF
git ls-files ":(attr:labelB)" ":(exclude,attr:labelC)sub/" >actual &&
test_cmp expect actual
'
test_expect_success 'fail on multiple attr specifiers in one pathspec item' '
test_must_fail git ls-files . ":(attr:labelB,attr:labelC)" 2>actual &&
test_grep "Only one" actual
'
test_expect_success 'fail if attr magic is used places not implemented' '
# The main purpose of this test is to check that we actually fail
# when you attempt to use attr magic in commands that do not implement
# attr magic. This test does not advocate git-add to stay that way,
# though, but git-add is convenient as it has its own internal pathspec
# parsing.
test_must_fail git add ":(attr:labelB)" 2>actual &&
test_grep "magic not supported" actual
'
test_expect_success 'abort on giving invalid label on the command line' '
test_must_fail git ls-files . ":(attr:☺)"
'
test_expect_success 'abort on asking for wrong magic' '
test_must_fail git ls-files . ":(attr:-label=foo)" &&
test_must_fail git ls-files . ":(attr:!label=foo)"
'
test_expect_success 'check attribute list' '
cat <<-EOF >>.gitattributes &&
* whitespace=indent,trail,space
EOF
git ls-files ":(attr:whitespace=indent\,trail\,space)" >actual &&
git ls-files >expect &&
test_cmp expect actual
'
test_expect_success 'backslash cannot be the last character' '
test_must_fail git ls-files ":(attr:label=foo\\ labelA=bar)" 2>actual &&
test_grep "not allowed as last character in attr value" actual
'
test_expect_success 'backslash cannot be used as a value' '
test_must_fail git ls-files ":(attr:label=f\\\oo)" 2>actual &&
test_grep "for value matching" actual
'
dir: match "attr" pathspec magic with correct paths The match_pathspec_item() function takes "prefix" value, allowing a caller to chop off the common leading prefix of pathspec pattern strings from the path and only use the remainder of the path to match the pathspec patterns (after chopping the same leading prefix of them, of course). This "common leading prefix" optimization has two main features: * discard the entries in the in-core index that are outside of the common leading prefix; if you are doing "ls-files one/a one/b", we know all matches must be from "one/", so first the code discards all entries outside the "one/" directory from the in-core index. This allows us to work on a smaller dataset. * allow skipping the comparison of the leading bytes when matching pathspec with path. When "ls-files" finds the path "one/a/1" in the in-core index given "one/a" and "one/b" as the pathspec, knowing that common leading prefix "one/" was found lets the pathspec matchinery not to bother comparing "one/" part, and allows it to feed "a/1" down, as long as the pathspec element "one/a" gets corresponding adjustment to "a". When the "attr" pathspec magic is in effect, however, the current code breaks down. The attributes, other than the ones that are built-in and the ones that come from the $GIT_DIR/info/attributes file and the top-level .gitattributes file, are lazily read from the filesystem on-demand, as we encounter each path and ask if it matches the pathspec. For example, if you say "git ls-files "(attr:label)sub/" in a repository with a file "sub/file" that is given the 'label' attribute in "sub/.gitattributes": * The common prefix optimization finds that "sub/" is the common prefix and prunes the in-core index so that it has only entries inside that directory. This is desirable. * The code then walks the in-core index, finds "sub/file", and eventually asks do_match_pathspec() if it matches the given pathspec. * do_match_pathspec() calls match_pathspec_item() _after_ stripping the common prefix "sub/" from the path, giving it "file", plus the length of the common prefix (4-bytes), so that the pathspec element "(attr:label)sub/" can be treated as if it were "(attr:label)". The last one is what breaks the match in the current code, as the pathspec subsystem ends up asking the attribute subsystem to find the attribute attached to the path "file". We need to ask about the attributes on "sub/file" when calling match_pathspec_attrs(); this can be done by looking at "prefix" bytes before the beginning of "name", which is the same trick already used by another piece of the code in the same match_pathspec_item() function. Unfortunately this was not discovered so far because the code works with slightly different arguments, e.g. $ git ls-files "(attr:label)sub" $ git ls-files "(attr:label)sub/" "no/such/dir/" would have reported "sub/file" as a path with the 'label' attribute just fine, because neither would trigger the common prefix optimization. Reported-by: Matthew Hughes <mhughes@uw.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-08 15:35:33 -06:00
test_expect_success 'reading from .gitattributes in a subdirectory (1)' '
git ls-files ":(attr:label1)" >actual &&
test_write_lines "sub/fileSetLabel" >expect &&
test_cmp expect actual
'
test_expect_success 'reading from .gitattributes in a subdirectory (2)' '
git ls-files ":(attr:label1)sub" >actual &&
test_write_lines "sub/fileSetLabel" >expect &&
test_cmp expect actual
'
test_expect_success 'reading from .gitattributes in a subdirectory (3)' '
git ls-files ":(attr:label1)sub/" >actual &&
test_write_lines "sub/fileSetLabel" >expect &&
test_cmp expect actual
'
test_done