2017-03-13 12:23:21 -06:00
|
|
|
#!/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
|
2018-11-18 09:48:00 -07:00
|
|
|
echo content >$path &&
|
2017-03-13 12:23:21 -06:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2018-11-18 09:48:00 -07:00
|
|
|
test_expect_success 'pathspec with labels and non existent .gitattributes (2)' '
|
|
|
|
test_must_fail git grep content HEAD -- ":(attr:label)"
|
|
|
|
'
|
|
|
|
|
2017-03-13 12:23:21 -06:00
|
|
|
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 &&
|
2017-03-13 12:23:21 -06:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2023-07-07 16:04:56 -06:00
|
|
|
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' '
|
2018-11-18 09:48:00 -07:00
|
|
|
cat <<-\EOF >expect &&
|
|
|
|
HEAD:fileSetLabel
|
|
|
|
HEAD:sub/fileSetLabel
|
|
|
|
EOF
|
|
|
|
git grep -l content HEAD ":(attr:label)" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2023-07-07 16:04:56 -06:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2017-03-13 12:23:21 -06:00
|
|
|
test_expect_success 'check specific unset attr' '
|
|
|
|
cat <<-\EOF >expect &&
|
|
|
|
fileUnsetLabel
|
|
|
|
sub/fileUnsetLabel
|
|
|
|
EOF
|
|
|
|
git ls-files ":(attr:-label)" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2018-11-18 09:48:00 -07:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2017-03-13 12:23:21 -06:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2018-11-18 09:48:00 -07:00
|
|
|
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)"
|
|
|
|
'
|
|
|
|
|
2017-03-13 12:23:21 -06:00
|
|
|
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
|
2017-03-13 12:23:21 -06:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2018-11-18 09:48:00 -07:00
|
|
|
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
|
2018-11-18 09:48:00 -07:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2017-03-13 12:23:21 -06:00
|
|
|
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
|
2017-03-13 12:23:21 -06:00
|
|
|
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 &&
|
2023-10-30 23:23:30 -06:00
|
|
|
test_grep "Only one" actual
|
2017-03-13 12:23:21 -06:00
|
|
|
'
|
|
|
|
|
|
|
|
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 &&
|
2023-10-30 23:23:30 -06:00
|
|
|
test_grep "magic not supported" actual
|
2017-03-13 12:23:21 -06:00
|
|
|
'
|
|
|
|
|
|
|
|
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)"
|
|
|
|
'
|
|
|
|
|
pathspec: allow escaped query values
In our own .gitattributes file we have attributes such as:
*.[ch] whitespace=indent,trail,space
When querying for attributes we want to be able to ask for the exact
value, i.e.
git ls-files :(attr:whitespace=indent,trail,space)
should work, but the commas are used in the attr magic to introduce
the next attr, such that this query currently fails with
fatal: Invalid pathspec magic 'trail' in ':(attr:whitespace=indent,trail,space)'
This change allows escaping characters by a backslash, such that the query
git ls-files :(attr:whitespace=indent\,trail\,space)
will match all path that have the value "indent,trail,space" for the
whitespace attribute. To accomplish this, we need to modify two places.
First `parse_long_magic` needs to not stop early upon seeing a comma or
closing paren that is escaped. As a second step we need to remove any
escaping from the attr value.
Based on a patch by Stefan Beller <sbeller@google.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-13 12:23:22 -06:00
|
|
|
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 &&
|
2023-10-30 23:23:30 -06:00
|
|
|
test_grep "not allowed as last character in attr value" actual
|
pathspec: allow escaped query values
In our own .gitattributes file we have attributes such as:
*.[ch] whitespace=indent,trail,space
When querying for attributes we want to be able to ask for the exact
value, i.e.
git ls-files :(attr:whitespace=indent,trail,space)
should work, but the commas are used in the attr magic to introduce
the next attr, such that this query currently fails with
fatal: Invalid pathspec magic 'trail' in ':(attr:whitespace=indent,trail,space)'
This change allows escaping characters by a backslash, such that the query
git ls-files :(attr:whitespace=indent\,trail\,space)
will match all path that have the value "indent,trail,space" for the
whitespace attribute. To accomplish this, we need to modify two places.
First `parse_long_magic` needs to not stop early upon seeing a comma or
closing paren that is escaped. As a second step we need to remove any
escaping from the attr value.
Based on a patch by Stefan Beller <sbeller@google.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-13 12:23:22 -06:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'backslash cannot be used as a value' '
|
|
|
|
test_must_fail git ls-files ":(attr:label=f\\\oo)" 2>actual &&
|
2023-10-30 23:23:30 -06:00
|
|
|
test_grep "for value matching" actual
|
pathspec: allow escaped query values
In our own .gitattributes file we have attributes such as:
*.[ch] whitespace=indent,trail,space
When querying for attributes we want to be able to ask for the exact
value, i.e.
git ls-files :(attr:whitespace=indent,trail,space)
should work, but the commas are used in the attr magic to introduce
the next attr, such that this query currently fails with
fatal: Invalid pathspec magic 'trail' in ':(attr:whitespace=indent,trail,space)'
This change allows escaping characters by a backslash, such that the query
git ls-files :(attr:whitespace=indent\,trail\,space)
will match all path that have the value "indent,trail,space" for the
whitespace attribute. To accomplish this, we need to modify two places.
First `parse_long_magic` needs to not stop early upon seeing a comma or
closing paren that is escaped. As a second step we need to remove any
escaping from the attr value.
Based on a patch by Stefan Beller <sbeller@google.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-13 12:23:22 -06:00
|
|
|
'
|
|
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2017-03-13 12:23:21 -06:00
|
|
|
test_done
|