2009-10-12 05:11:57 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='ls-files --exclude does not affect index files'
|
2021-10-12 13:56:42 +00:00
|
|
|
|
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2009-10-12 05:11:57 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'create repo with file' '
|
|
|
|
echo content >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m file &&
|
|
|
|
echo modification >file
|
|
|
|
'
|
|
|
|
|
|
|
|
check_output() {
|
|
|
|
test_expect_success "ls-files output contains file ($1)" "
|
|
|
|
echo '$2' >expect &&
|
|
|
|
git ls-files --exclude-standard --$1 >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
"
|
|
|
|
}
|
|
|
|
|
|
|
|
check_all_output() {
|
|
|
|
check_output 'cached' 'file'
|
|
|
|
check_output 'modified' 'file'
|
|
|
|
}
|
|
|
|
|
|
|
|
check_all_output
|
|
|
|
test_expect_success 'add file to gitignore' '
|
|
|
|
echo file >.gitignore
|
|
|
|
'
|
|
|
|
check_all_output
|
|
|
|
|
ls-files: error out on -i unless -o or -c are specified
ls-files --ignored can be used together with either --others or
--cached. After being perplexed for a bit and digging in to the code, I
assumed that ls-files -i was just broken and not printing anything and
I had a nice patch ready to submit when I finally realized that -i can be
used with --cached to find tracked ignores.
While that was a mistake on my part, and a careful reading of the
documentation could have made this more clear, I suspect this is an
error others are likely to make as well. In fact, of two uses in our
testsuite, I believe one of the two did make this error. In t1306.13,
there are NO tracked files, and all the excludes built up and used in
that test and in previous tests thus have to be about untracked files.
However, since they were looking for an empty result, the mistake went
unnoticed as their erroneous command also just happened to give an empty
answer.
-i will most the time be used with -o, which would suggest we could just
make -i imply -o in the absence of either a -o or -c, but that would be
a backward incompatible break. Instead, let's just flag -i without
either a -o or -c as an error, and update the two relevant testcases to
specify their intent.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-12 17:28:16 +00:00
|
|
|
test_expect_success 'ls-files -i -c lists only tracked-but-ignored files' '
|
ls-files: unbreak "ls-files -i"
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30 19:05:52 +00:00
|
|
|
echo content >other-file &&
|
|
|
|
git add other-file &&
|
|
|
|
echo file >expect &&
|
ls-files: error out on -i unless -o or -c are specified
ls-files --ignored can be used together with either --others or
--cached. After being perplexed for a bit and digging in to the code, I
assumed that ls-files -i was just broken and not printing anything and
I had a nice patch ready to submit when I finally realized that -i can be
used with --cached to find tracked ignores.
While that was a mistake on my part, and a careful reading of the
documentation could have made this more clear, I suspect this is an
error others are likely to make as well. In fact, of two uses in our
testsuite, I believe one of the two did make this error. In t1306.13,
there are NO tracked files, and all the excludes built up and used in
that test and in previous tests thus have to be about untracked files.
However, since they were looking for an empty result, the mistake went
unnoticed as their erroneous command also just happened to give an empty
answer.
-i will most the time be used with -o, which would suggest we could just
make -i imply -o in the absence of either a -o or -c, but that would be
a backward incompatible break. Instead, let's just flag -i without
either a -o or -c as an error, and update the two relevant testcases to
specify their intent.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-12 17:28:16 +00:00
|
|
|
git ls-files -i -c --exclude-standard >output &&
|
ls-files: unbreak "ls-files -i"
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30 19:05:52 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2009-10-12 05:11:57 +00:00
|
|
|
test_done
|