summaryrefslogtreecommitdiff
path: root/t/t3003-ls-files-exclude.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12leak tests: mark some ls-files tests as passing with SANITIZE=leakLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Mark some tests that match "*ls-files*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). We still have others that match '*ls-files*" that fail under SANITIZE=leak. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-13ls-files: error out on -i unless -o or -c are specifiedLibravatar Elijah Newren1-2/+2
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>
2009-10-30ls-files: unbreak "ls-files -i"Libravatar Jeff King1-0/+8
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-12ls-files: excludes should not impact tracked filesLibravatar Jeff King1-0/+32
In all parts of git, .gitignore and other exclude files impact only how we treat untracked files; they should have no effect on files listed in the index. This behavior was originally implemented very early on in 9ff768e, but only for --exclude-from. Later, commit 63d285c accidentally caused us to trigger the behavior for --exclude-per-directory. This patch totally ignores excludes for files found in the index. This means we are reversing the original intent of 9ff768e, while at the same time fixing the accidental behavior of 63d285c. This is a good thing, though, as the way that 9ff768e behaved does not really make sense with the way exclusions are used in modern git. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>