summaryrefslogtreecommitdiff
path: root/t/t0008-ignores.sh
Commit message (Collapse)AuthorAgeFilesLines
* check-ignore: Add option to ignore index contentsdw/check-ignore-sans-indexDave Williams2013-09-121-9/+63
| | | | | | | | | | | | | | | | | | | | check-ignore currently shows how .gitignore rules would treat untracked paths. Tracked paths do not generate useful output. This prevents debugging of why a path became tracked unexpectedly unless that path is first removed from the index with `git rm --cached <path>`. The option --no-index tells the command to bypass the check for the path being in the index and hence allows tracked paths to be checked too. Whilst this behaviour deviates from the characteristics of `git add` and `git status` its use case is unlikely to cause any user confusion. Test scripts are augmented to check this option against the standard ignores to ensure correct behaviour. Signed-off-by: Dave Williams <dave@opensourcesolutions.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0008: avoid SIGPIPE race condition on fifojk/t0008-sigpipe-fixJeff King2013-07-121-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To test check-ignore's --stdin feature, we use two fifos to send and receive data. We carefully keep a descriptor to its input open so that it does not receive EOF between input lines. However, we do not do the same for its output. That means there is a potential race condition in which check-ignore has opened the output pipe once (when we read the first line), and then writes the second line before we have re-opened the pipe. In that case, check-ignore gets a SIGPIPE and dies. The outer shell then tries to open the output fifo but blocks indefinitely, because there is no writer. We can fix it by keeping a descriptor open through the whole procedure. This should also help if check-ignore dies for any other reason (we would already have opened the fifo and would therefore not block, but just get EOF on read). However, we are technically still susceptible to check-ignore dying early, before we have opened the fifo. This is an unlikely race and shouldn't generally happen in practice, though, so we can hopefully ignore it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0008: use named pipe (FIFO) to test check-ignore streamingAdam Spiers2013-04-291-21/+17
| | | | | | | | | | | | | | | sleeps in the check-ignore test suite are not ideal since they can fail when the system is under load, or when a tool like valgrind is used which drastically alters the timing. Therefore we replace them with a more robust solution using a named pipe (FIFO). Thanks to Jeff King for coming up with the redirection wizardry required to make this work. http://article.gmane.org/gmane.comp.version-control.git/220916 Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* check-ignore: allow incremental streaming of queries via --stdinAdam Spiers2013-04-111-5/+23
| | | | | | | | | | | | | | | | | | | | | | Some callers, such as the git-annex web assistant, find it useful to invoke git check-ignore as a persistent background process, which can then have queries fed to its STDIN at any point, and the corresponding response consumed from its STDOUT. For this we need to invoke check_ignore() once per line of standard input, and flush standard output after each result. The above use case suggests that empty STDIN is actually a reasonable scenario (e.g. when the caller doesn't know in advance whether any queries need to be fed to the background process until after it's already started), so we make the minor behavioural change that "no pathspec given." is no longer emitted in when STDIN is empty. Even though check_ignore() could now be changed to operate on a single pathspec, we keep it operating on an array of pathspecs since that is a more convenient way of consuming the existing pathspec API. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* check-ignore: add -n / --non-matching optionAdam Spiers2013-04-111-32/+90
| | | | | | | | | | | | | | | If `-n` or `--non-matching` are specified, non-matching pathnames will also be output, in which case all fields in each output record except for <pathname> will be empty. This can be useful when running check-ignore as a background process, so that files can be incrementally streamed to STDIN, and for each of these files, STDOUT will indicate whether that file matched a pattern or not. (Without this option, it would be impossible to tell whether the absence of output for a given file meant that it didn't match any pattern, or that the result simply hadn't been flushed to STDOUT yet.) Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0008: remove duplicated test fixture dataAdam Spiers2013-04-111-15/+1
| | | | | | | | | | The expected contents of STDOUT for the final --stdin tests can be derived from the expected contents of STDOUT for the same tests when --verbose is given, in the same way that test_expect_success_multi derives this for earlier tests. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* name-hash: allow hashing an empty stringJunio C Hamano2013-02-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Usually we do not pass an empty string to the function hash_name() because we almost always ask for hash values for a path that is a candidate to be added to the index. However, check-ignore (and most likely check-attr, but I didn't check) apparently has a callchain to ask the hash value for an empty path when it was given a "." from the top-level directory to ask "Is the path . excluded by default?" Make sure that hash_name() does not overrun the end of the given pathname even when it is empty. Remove a sweep-the-issue-under-the-rug conditional in check-ignore that avoided to pass an empty string to the callchain while at it. It is a valid question to ask for check-ignore if the top-level is set to be ignored by default, even though the answer is most likely no, if only because there is currently no way to specify such an entry in the .gitignore file. But it is an unusual thing to ask and it is not worth optimizing for it by special casing at the top level of the call chain. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0008: document test_expect_success_multiAdam Spiers2013-02-191-0/+10
| | | | | | | | | | | test_expect_success_multi() helper function warrants some explanation, since at first sight it may seem like generic test framework plumbing, but is in fact specific to testing check-ignore, and allows more thorough testing of the various output formats without significantly increase the size of t0008. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t0008: avoid brace expansionRené Scharfe2013-01-101-2/+7
| | | | | | | | | | Brace expansion is a shell feature that's not required by POSIX and not supported by dash nor NetBSD's sh. Explicitly list all combinations instead. Also avoid calling touch by creating the test files with a redirection instead, as suggested by Junio. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add git-check-ignore sub-commandAdam Spiers2013-01-061-0/+632
This works in a similar manner to git-check-attr. Thanks to Jeff King and Junio C Hamano for the idea: http://thread.gmane.org/gmane.comp.version-control.git/108671/focus=108815 Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>