summaryrefslogtreecommitdiff
path: root/t/test-lib.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-05-17Merge branch 'jk/test-send-sh-x-trace-elsewhere'Libravatar Junio C Hamano1-0/+13
Running tests with '-x' option to trace the individual command executions is a useful way to debug test scripts, but some tests that capture the standard error stream and check what the command said can be broken with the trace output mixed in. When running our tests under "bash", however, we can redirect the trace output to another file descriptor to keep the standard error of programs being tested intact. * jk/test-send-sh-x-trace-elsewhere: test-lib: set BASH_XTRACEFD automatically
2016-05-11test-lib: set BASH_XTRACEFD automaticallyLibravatar Jeff King1-0/+13
Passing "-x" to a test script enables the shell's "set -x" tracing, which can help with tracking down the command that is causing a failure. Unfortunately, it can also _cause_ failures in some tests that redirect the stderr of a shell function. Inside the function the shell continues to respect "set -x", and the trace output is collected along with whatever stderr is generated normally by the function. You can see an example of this by running: ./t0040-parse-options.sh -x -i which will fail immediately in the first test, as it expects: test_must_fail some-cmd 2>output.err to leave output.err empty (but with "-x" it has our trace output). Unfortunately there isn't a portable or scalable solution to this. We could teach test_must_fail to disable "set -x", but that doesn't help any of the other functions or subshells. However, we can work around it by pointing the "set -x" output to our descriptor 4, which always points to the original stderr of the test script. Unfortunately this only works for bash, but it's better than nothing (and other shells will just ignore the BASH_XTRACEFD variable). The patch itself is a simple one-liner, but note the caveats in the accompanying comments. Automatic tests for our "-x" option may be a bit too meta (and a pain, because they are bash-specific), but I did confirm that it works correctly both with regular "-x" and with "--verbose-only=1". This works because the latter flips "set -x" off and on for particular tests (if it didn't, we would get tracing for all tests, as going to descriptor 4 effectively circumvents the verbose flag). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-03Merge branch 'sg/test-lib-simplify-expr-away'Libravatar Junio C Hamano1-5/+5
Code cleanup. * sg/test-lib-simplify-expr-away: test-lib: simplify '--option=value' parsing
2016-04-22test-lib: simplify '--option=value' parsingLibravatar SZEDER Gábor1-5/+5
To get the 'value' from '--option=value', test-lib.sh parses said option running 'expr' with a regexp. This involves a subshell, an external process, and a lot of non-alphanumeric characters in the regexp. Use a much simpler POSIX-defined shell parameter expansion instead to do the same. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-15test helpers: move test-* to t/helper/ subdirectoryLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This keeps top dir a bit less crowded. And because these programs are for testing purposes, it makes sense that they stay somewhere in t/ Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17Merge branch 'js/mingw-tests'Libravatar Junio C Hamano1-1/+1
Test scripts have been updated to remove assumptions that are not portable between Git for POSIX and Git for Windows, or to skip ones with expectations that are not satisfiable on Git for Windows. * js/mingw-tests: (21 commits) gitignore: ignore generated test-fake-ssh executable mingw: do not bother to test funny file names mingw: skip a test in t9130 that cannot pass on Windows mingw: handle the missing POSIXPERM prereq in t9124 mingw: avoid illegal filename in t9118 mingw: mark t9100's test cases with appropriate prereqs t0008: avoid absolute path mingw: work around pwd issues in the tests mingw: fix t9700's assumption about directory separators mingw: skip test in t1508 that fails due to path conversion tests: turn off git-daemon tests if FIFOs are not available mingw: disable mkfifo-based tests mingw: accomodate t0060-path-utils for MSYS2 mingw: fix t5601-clone.sh mingw: let lstat() fail with errno == ENOTDIR when appropriate mingw: try to delete target directory before renaming mingw: prepare the TMPDIR environment variable for shell scripts mingw: factor out Windows specific environment setup Git.pm: stop assuming that absolute paths start with a slash mingw: do not trust MSYS2's MinGW gettext.sh ...
2016-02-10Merge branch 'js/test-lib-windows-emulated-yes'Libravatar Junio C Hamano1-2/+4
The emulated "yes" command used in our test scripts has been tweaked not to spend too much time generating unnecessary output that is not used, to help those who test on Windows where it would not stop until it fills the pipe buffer due to lack of SIGPIPE. * js/test-lib-windows-emulated-yes: test-lib: limit the output of the yes utility
2016-02-02test-lib: limit the output of the yes utilityLibravatar Johannes Schindelin1-2/+4
On Windows, there is no SIGPIPE. A consequence of this is that the upstream process of a pipe does not notice the death of the downstream process until the pipe buffer is full and writing more data returns an error. This behavior is the reason for an annoying delay during the execution of t7610-mergetool.sh: There are a number of test cases where 'yes' is invoked upstream. Since the utility is basically an endless loop it runs, on Windows, until the pipe buffer is full. This does take a few seconds. The test suite has its own implementation of 'yes'. Modify it to produce only a limited amount of output that is sufficient for the test suite. The amount chosen should be sufficiently high for any test case, assuming that future test cases will not exaggerate their demands of input from an upstream 'yes' invocation. [j6t: commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28Merge branch 'jk/sanity'Libravatar Junio C Hamano1-5/+13
The description for SANITY prerequisite the test suite uses has been clarified both in the comment and in the implementation. * jk/sanity: test-lib: clarify and tighten SANITY
2016-01-27mingw: disable mkfifo-based testsLibravatar Johannes Schindelin1-1/+1
MSYS2 (the POSIX emulation layer used by Git for Windows' Bash) actually has a working mkfifo. The only problem is that it is only emulating named pipes through the MSYS2 runtime; The Win32 API has no idea about named pipes, hence the Git executable cannot access those pipes either. The symptom is that Git fails with a '<name>: No such file or directory' because MSYS2 emulates named pipes through special-crafted '.lnk' files. The solution is to tell the test suite explicitly that we cannot use named pipes when we want to test on Windows. This lets t4056-diff-order.sh, t9010-svn-fe.sh and t9300-fast-import.sh pass. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19test-lib: clarify and tighten SANITYLibravatar Junio C Hamano1-5/+13
f400e51c (test-lib.sh: set prerequisite SANITY by testing what we really need, 2015-01-27) improved the way SANITY prerequisite was determined, but made the resulting code (incorrectly) imply that SANITY is all about effects of permission bits of the containing directory has on the files contained in it by the comment it added, its log message and the actual tests. State what SANITY is about more clearly in the comment, and test that a file whose permission bits says should be unreadble truly cannot be read. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-19Merge branch 'jk/test-with-x'Libravatar Junio C Hamano1-2/+11
Running tests with the "-x" option to make them verbose had some unpleasant interactions with other features of the test suite. * jk/test-with-x: test-lib: disable trace when test is not verbose test-lib: turn off "-x" tracing during chain-lint check
2015-08-07test-lib: disable trace when test is not verboseLibravatar Jeff King1-2/+6
The "-x" test-script option turns on the shell's "-x" tracing, which can help show why a particular test is failing. Unfortunately, this can create false negatives in some tests if they invoke a shell function with its stderr redirected. t5512.10 is such a test, as it does: test_must_fail git ls-remote refs*master >actual 2>&1 && test_cmp exp actual The "actual" file gets the "-x" trace for the test_must_fail function, which prevents it from matching the expected output. There's no way to avoid this without managing the trace flag inside each sub-function, which isn't really a workable solution. But unless you specifically care about t5512.10, we can work around it by enabling tracing only for the specific tests we want. You can already do: ./t5512-ls-remote.sh -x --verbose-only=16 to see the trace only for a specific test. But that doesn't _disable_ the tracing in the other tests; it just sends it to /dev/null. However, there's no point in generating a trace that the user won't see, so we can simply disable tracing whenever it doesn't have a matching verbose flag. The normal case of just "./t5512-ls-remote.sh -x" stays the same, as "-x" already implies "--verbose" (and "--verbose-only" overrides "--verbose", which is why this works at all). And for our test, we need only check $verbose, as maybe_setup_verbose will have already set that flag based on the $verbose_only list). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-07test-lib: turn off "-x" tracing during chain-lint checkLibravatar Jeff King1-0/+5
Now that GIT_TEST_CHAIN_LINT is on by default, running: ./t0000-basic.sh -x --verbose-only=1 starts with: expecting success: find .git/objects -type f -print >should-be-empty && test_line_count = 0 should-be-empty + exit 117 error: last command exited with $?=117 + find .git/objects -type f -print + test_line_count = 0 should-be-empty + test 3 != 3 + wc -l + test 0 = 0 ok 1 - .git/objects should be empty after git init in an empty repo This is confusing, as the "exit 117" line and the error line (which is printed in red, no less!) are not part of the test at all, but are rather in the separate chain-lint test_eval. Let's unset the "trace" variable when eval-ing the chain lint check, which avoids this. Note that we cannot just do a one-shot variable like: trace= test_eval ... as the behavior of one-shot variables for function calls is not portable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-27Merge branch 'rh/test-color-avoid-terminfo-in-original-home' into maintLibravatar Junio C Hamano1-52/+47
An ancient test framework enhancement to allow color was not entirely correct; this makes it work even when tput needs to read from the ~/.terminfo under the user's real HOME directory. * rh/test-color-avoid-terminfo-in-original-home: test-lib.sh: fix color support when tput needs ~/.terminfo Revert "test-lib.sh: do tests for color support after changing HOME"
2015-07-10Merge branch 'rh/test-color-avoid-terminfo-in-original-home'Libravatar Junio C Hamano1-52/+47
An ancient test framework enhancement to allow color was not entirely correct; this makes it work even when tput needs to read from the ~/.terminfo under the user's real HOME directory. * rh/test-color-avoid-terminfo-in-original-home: test-lib.sh: fix color support when tput needs ~/.terminfo Revert "test-lib.sh: do tests for color support after changing HOME"
2015-06-17test-lib.sh: fix color support when tput needs ~/.terminfoLibravatar Richard Hansen1-29/+28
If tput needs ~/.terminfo for the current $TERM, then tput will succeed before HOME is changed to $TRASH_DIRECTORY (causing color to be set to 't') but fail afterward. One possible way to fix this is to treat HOME like TERM: back up the original value and temporarily restore it before say_color() runs tput. Instead, pre-compute and save the color control sequences before changing either TERM or HOME. Use the saved control sequences in say_color() rather than call tput each time. This avoids the need to back up and restore the TERM and HOME variables, and it avoids the overhead of a subshell and two invocations of tput per call to say_color(). Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-17Revert "test-lib.sh: do tests for color support after changing HOME"Libravatar Richard Hansen1-47/+43
This reverts commit 102fc80d32094ad6598b17ab9d607516ee8edc4a. There are two issues with that commit: * It is buggy. In pseudocode, it is doing: color is set || TERM != dumb && color works && color=t when it should be doing: color is set || { TERM != dumb && color works && color=t } * It unnecessarily disables color when tput needs to read ~/.terminfo to get the control sequences. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Merge branch 'jk/test-chain-lint'Libravatar Junio C Hamano1-1/+1
Developer support to automatically detect broken &&-chain in the test scripts is now turned on by default. * jk/test-chain-lint: test-lib: turn on GIT_TEST_CHAIN_LINT by default t7502-commit.sh: fix a broken and-chain
2015-04-28test-lib: turn on GIT_TEST_CHAIN_LINT by defaultLibravatar Jeff King1-1/+1
Now that the feature has had time to prove itself, and any topics in flight have had a chance to clean up any broken &&-chains, we can flip this feature on by default. This makes one less thing submitters need to configure or check before sending their patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-26Merge branch 'jk/test-chain-lint'Libravatar Junio C Hamano1-0/+16
People often forget to chain the commands in their test together with &&, leaving a failure from an earlier command in the test go unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to catch such a mistake more easily. * jk/test-chain-lint: (36 commits) t9001: drop save_confirm helper t0020: use test_* helpers instead of hand-rolled messages t: simplify loop exit-code status variables t: fix some trivial cases of ignored exit codes in loops t7701: fix ignored exit code inside loop t3305: fix ignored exit code inside loop t0020: fix ignored exit code inside loops perf-lib: fix ignored exit code inside loop t6039: fix broken && chain t9158, t9161: fix broken &&-chain in git-svn tests t9104: fix test for following larger parents t4104: drop hand-rolled error reporting t0005: fix broken &&-chains t7004: fix embedded single-quotes t0050: appease --chain-lint t9001: use test_when_finished t4117: use modern test_* helpers t6034: use modern test_* helpers t1301: use modern test_* helpers t0020: use modern test_* helpers ...
2015-03-20t/test-lib: introduce --chain-lint optionLibravatar Jeff King1-0/+16
It's easy to miss an "&&"-chain in a test script, like: test_expect_success 'check something important' ' cmd1 && cmd2 cmd3 ' The test harness will notice if cmd3 fails, but a failure of cmd1 or cmd2 will go unnoticed, as their exit status is lost after cmd3 runs. The toy example above is easy to spot because the "cmds" are all the same length, but real code is much more complicated. It's also difficult to detect these situations by statically analyzing the shell code with regexps (like the check-non-portable-shell script does); there's too much context required to know whether a &&-chain is appropriate on a given line or not. This patch instead lets the shell check each test by sticking a command with a specific and unusual return code at the top of each test, like: (exit 117) && cmd1 && cmd2 cmd3 In a well-formed test, the non-zero exit from the first command prevents any of the rest from being run, and the test's exit code is 117. In a bad test (like the one above), the 117 is lost, and cmd3 is run. When we encounter a failure of this check, we abort the test script entirely. For one thing, we have no clue which subset of the commands in the test snippet were actually run. Running further tests would be pointless, because we're now in an unknown state. And two, this is not a "test failure" in the traditional sense. The test script is buggy, not the code it is testing. We should be able to fix these problems in the script once, and not have them come back later as a regression in git's code. After checking a test snippet for --chain-lint, we do still run the test itself. We could actually have a pure-lint mode which just checks each test, but there are a few reasons not to. One, because the tests are executing arbitrary code, which could impact the later environment (e.g., that could impact which set of tests we run at all). And two, because a pure-lint mode would still be expensive to run, because a significant amount of code runs outside of the test_expect_* blocks. Instead, this option is designed to be used as part of a normal test suite run, where it adds very little overhead. Turning on this option detects quite a few problems in existing tests, which will be fixed in subsequent patches. However, there are a number of places it cannot reach: - it cannot find a failure to break out of loops on error, like: cmd1 && for i in a b c; do cmd2 $i done && cmd3 which will not notice failures of "cmd2 a" or "cmd b" - it cannot find a missing &&-chain inside a block or subfunction, like: foo () { cmd1 cmd2 } foo && bar which will not notice a failure of cmd1. - it only checks tests that you run; every platform will have some tests skipped due to missing prequisites, so it's impossible to say from one run that the test suite is free of broken &&-chains. However, all tests get run by _somebody_, so eventually we will notice problems. - it does not operate on test_when_finished or prerequisite blocks. It could, but these tends to be much shorter and less of a problem, so I punted on them in this patch. This patch was inspired by an earlier patch by Jonathan Nieder: http://article.gmane.org/gmane.comp.version-control.git/235913 This implementation and all bugs are mine. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-12t5541: move run_with_cmdline_limit to test-lib.shLibravatar Jeff King1-0/+6
We use this to test http pushing with a restricted commandline. Other scripts (like t5551, which does http fetching) will want to use it, too. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-12t: redirect stderr GIT_TRACE to descriptor 4Libravatar Jeff King1-4/+1
If you run a test script like: GIT_TRACE=1 ./t0061-run-command.sh you may get test failures, because some tests capture and check the stderr output from git commands (and with GIT_TRACE set to 1, the trace output will be included there). When we see GIT_TRACE set like this, we print a warning to the user. However, we can do even better than that by just pointing it to descriptor 4, which all tests leave connected to the test script's stderr. That's likely what the user intended (and any scripts that do want to see GIT_TRACE output will set GIT_TRACE themselves). Not only does this avoid false negatives in the tests, but it means the user will actually see trace output for git calls that redirect their stderr (whereas before, it was sometimes confusingly buried in a file). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-12t: translate SIGINT to an exitLibravatar Jeff King1-0/+1
Right now if a test script receives SIGINT (e.g., because a test was hanging and the user hit ^C), the shell exits immediately. This can be annoying if the test script did any global setup, like starting apache or git-daemon, as it will not have an opportunity to clean up after itself. A subsequent run of the test won't be able to start its own daemon, and will either fail or skip the tests. Instead, let's trap SIGINT to make sure we do a clean shutdown, and just chain it to a normal exit (which will trigger any cleanup). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-05Merge branch 'jk/sanity' into maintLibravatar Junio C Hamano1-3/+27
The tests that wanted to see that file becomes unreadable after running "chmod a-r file", and the tests that wanted to make sure it is not run as root, we used "can we write into the / directory?" as a cheap substitute, but on some platforms that is not a good heuristics. The tests and their prerequisites have been updated to check what they really require. * jk/sanity: test-lib.sh: set prerequisite SANITY by testing what we really need tests: correct misuses of POSIXPERM t/lib-httpd: switch SANITY check for NOT_ROOT
2015-02-25Merge branch 'jk/sanity'Libravatar Junio C Hamano1-3/+27
The tests that wanted to see that file becomes unreadable after running "chmod a-r file", and the tests that wanted to make sure it is not run as root, we used "can we write into the / directory?" as a cheap substitute, but on some platforms that is not a good heuristics. The tests and their prerequisites have been updated to check what they really require. * jk/sanity: test-lib.sh: set prerequisite SANITY by testing what we really need tests: correct misuses of POSIXPERM t/lib-httpd: switch SANITY check for NOT_ROOT
2015-02-15test-lib.sh: set prerequisite SANITY by testing what we really needLibravatar Torsten Bögershausen1-3/+22
What we wanted out of the SANITY precondition is that the filesystem behaves sensibly with permission bits settings. - You should not be able to remove a file in a read-only directory, - You should not be able to tell if a file in a directory exists if the directory lacks read or execute permission bits. We used to cheat by approximating that condition with "is the / writable?" test and/or "are we running as root?" test. Neither test is sufficient or appropriate in environments like Cygwin. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16t/lib-httpd: switch SANITY check for NOT_ROOTLibravatar Jeff King1-0/+5
The SANITY prerequisite is really about whether the filesystem will respect the permissions we set, and being root is only one part of that. But the httpd tests really just care about not being root, as they are trying to avoid weirdness in apache (see a1a3011 for details). Let's switch out SANITY for a new NOT_ROOT prerequisite, which will let us tweak SANITY more freely. We implement NOT_ROOT by checking `id -u`, which is in POSIX and seems to be available even on MSYS. Note that we cannot just call this "ROOT" and ask for "!ROOT". The possible outcomes are: 1. we know we are root 2. we know we are not root 3. we could not tell, because `id` was not available We should conservatively treat (3) as "does not have the prerequisite", which means that a naive negation would not work. Helped-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07test-lib.sh: do tests for color support after changing HOMELibravatar Richard Hansen1-43/+47
If ncurses needs ~/.terminfo for the current $TERM, then tput will succeed before changing HOME to $TRASH_DIRECTORY but fail afterward. Move the tests that determine whether there is color support after changing HOME so that color=t is set if and only if tput would succeed when say_color() is run. Note that color=t is now set after --no-color is processed, so the condition to set color=t has changed: it is now set only if color has not already been set to the empty string by --no-color. This disables color support for those that need ~/.terminfo for their TERM, but it's better than filling the screen with: tput: unknown terminal "custom-terminal-name-here" An alternative would be to symlink or copy the user's terminfo database into $TRASH_DIRECTORY, but this is tricky due to the lack of a standard name for the terminfo database (for example, instead of a ~/.terminfo directory, NetBSD uses a ~/.terminfo.cdb database file). Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07test-lib: use 'test ...' instead of '[ ... ]'Libravatar Richard Hansen1-3/+3
(see Documentation/CodingGuidelines) Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-22Merge branch 'jk/test-asan'Libravatar Junio C Hamano1-0/+3
* jk/test-asan: t: support clang/gcc AddressSanitizer
2014-12-17Sync with v2.1.4Libravatar Junio C Hamano1-1/+5
* maint-2.1: Git 2.1.4 Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v2.0.5Libravatar Junio C Hamano1-1/+5
* maint-2.0: Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v1.9.5Libravatar Junio C Hamano1-1/+5
* maint-1.9: Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v1.8.5.6Libravatar Junio C Hamano1-1/+5
* maint-1.8.5: Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17read-cache: optionally disallow HFS+ .git variantsLibravatar Jeff King1-1/+5
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for HFS+; let's use it in verify_path. We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on HFS+. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectHFS config option. Though this is expected to be most useful on OS X, we allow it to be set everywhere, as HFS+ may be mounted on other platforms. The variable does default to on for OS X, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-11t: support clang/gcc AddressSanitizerLibravatar Jeff King1-0/+3
When git is compiled with "-fsanitize=address" (using clang or gcc >= 4.8), all invocations of git will check for buffer overflows. This is similar to running with valgrind, except that it is more thorough (because of the compiler support, function-local buffers can be checked, too) and runs much faster (making it much less painful to run the whole test suite with the checks turned on). Unlike valgrind, the magic happens at compile-time, so we don't need the same infrastructure in the test suite that we did to support --valgrind. But there are two things we can help with: 1. On some platforms, the leak-detector is on by default, and causes every invocation of "git init" (and thus every test script) to fail. Since running git with the leak detector is pointless, let's shut it off automatically in the tests, unless the user has already configured it. 2. When apache runs a CGI, it clears the environment of unknown variables. This means that the $ASAN_OPTIONS config doesn't make it to git-http-backend, and it dies due to the leak detector. Let's mark the variable as OK for apache to pass. With these two changes, running make CC=clang CFLAGS=-fsanitize=address test works out of the box. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-13test-lib.sh: support -x option for shell-tracingLibravatar Jeff King1-4/+38
Usually running a test under "-v" makes it clear which command is failing. However, sometimes it can be useful to also see a complete trace of the shell commands being run in the test. You can do so without any support from the test suite by running "sh -x tXXXX-foo.sh". However, this produces quite a large bit of output, as we see a trace of the entire test suite. This patch instead introduces a "-x" option to the test scripts (i.e., "./tXXXX-foo.sh -x"). When enabled, this turns on "set -x" only for the tests themselves. This can still be a bit verbose, but should keep things to a more manageable level. You can even use "--verbose-only" to see the trace only for a specific test. The implementation is a little invasive. We turn on the "set -x" inside the "eval" of the test code. This lets the eval itself avoid being reported in the trace (which would be long, and redundant with the verbose listing we already showed). And then after the eval runs, we do some trickery with stderr to avoid showing the "set +x" to the user. We also show traces for test_cleanup functions (since they can impact the test outcome, too). However, we do avoid running the noop ":" cleanup (the default if the test does not use test_cleanup at all), as it creates unnecessary noise in the "set -x" output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-08Merge branch 'jc/push-cert'Libravatar Junio C Hamano1-1/+2
Allow "git push" request to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to "trust" the server. * jc/push-cert: (24 commits) receive-pack::hmac_sha1(): copy the entire SHA-1 hash out signed push: allow stale nonce in stateless mode signed push: teach smart-HTTP to pass "git push --signed" around signed push: fortify against replay attacks signed push: add "pushee" header to push certificate signed push: remove duplicated protocol info send-pack: send feature request on push-cert packet receive-pack: GPG-validate push certificates push: the beginning of "git push --signed" pack-protocol doc: typofix for PKT-LINE gpg-interface: move parse_signature() to where it should be gpg-interface: move parse_gpg_output() to where it should be send-pack: clarify that cmds_sent is a boolean send-pack: refactor inspecting and resetting status and sending commands send-pack: rename "new_refs" to "need_pack_data" receive-pack: factor out capability string generation send-pack: factor out capability string generation send-pack: always send capabilities send-pack: refactor decision to send update per ref send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher ...
2014-09-19Merge branch 'tb/crlf-tests'Libravatar Junio C Hamano1-0/+1
* tb/crlf-tests: MinGW: update tests to handle a native eol of crlf Makefile: propagate NATIVE_CRLF to C t0027: Tests for core.eol=native, eol=lf, eol=crlf
2014-09-17signed push: teach smart-HTTP to pass "git push --signed" aroundLibravatar Junio C Hamano1-1/+2
The "--signed" option received by "git push" is first passed to the transport layer, which the native transport directly uses to notice that a push certificate needs to be sent. When the transport-helper is involved, however, the option needs to be told to the helper with set_helper_option(), and the helper needs to take necessary action. For the smart-HTTP helper, the "necessary action" involves spawning the "git send-pack" subprocess with the "--signed" option. Once the above all gets wired in, the smart-HTTP transport now can use the push certificate mechanism to authenticate its pushes. Add a test that is modeled after tests for the native transport in t5534-push-signed.sh to t5541-http-push-smart.sh. Update the test Apache configuration to pass GNUPGHOME environment variable through. As PassEnv would trigger warnings for an environment variable that is not set, export it from test-lib.sh set to a harmless value when GnuPG is not being used in the tests. Note that the added test is deliberately loose and does not check the nonce in this step. This is because the stateless RPC mode is inevitably flaky and a nonce that comes back in the actual push processing is one issued by a different process; if the two interactions with the server crossed a second boundary, the nonces will not match and such a check will fail. A later patch in the series will work around this shortcoming. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-09Merge branch 'jc/not-mingw-cygwin'Libravatar Junio C Hamano1-4/+0
We have been using NOT_{MINGW,CYGWIN} test prerequisites long before Peff invented support for negated prerequisites e.g. !MINGW and we still add more uses of the former. Convert them to the latter to avoid confusion. * jc/not-mingw-cygwin: test prerequisites: enumerate with commas test prerequisites: eradicate NOT_FOO
2014-09-02MinGW: update tests to handle a native eol of crlfLibravatar Brice Lambson1-0/+1
Some of the tests were written with the assumption that the native eol would always be lf. After defining NATIVE_CRLF on MinGW, these tests began failing. This change will update the tests to also handle a native eol of crlf. Signed-off-by: Brice Lambson <bricelam@live.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-22Merge branch 'kb/perf-trace'Libravatar Junio C Hamano1-0/+4
* kb/perf-trace: api-trace.txt: add trace API documentation progress: simplify performance measurement by using getnanotime() wt-status: simplify performance measurement by using getnanotime() git: add performance tracing for git's main() function to debug scripts trace: add trace_performance facility to debug performance issues trace: add high resolution timer function to debug performance issues trace: add 'file:line' to all trace output trace: move code around, in preparation to file:line output trace: add current timestamp to all trace output trace: disable additional trace output for unit tests trace: add infrastructure to augment trace output with additional info sha1_file: change GIT_TRACE_PACK_ACCESS logging to use trace API Documentation/git.txt: improve documentation of 'GIT_TRACE*' variables trace: improve trace performance trace: remove redundant printf format attribute trace: consistently name the format parameter trace: move trace declarations from cache.h to new trace.h
2014-07-21test prerequisites: eradicate NOT_FOOLibravatar Junio C Hamano1-4/+0
Support for Back when bdccd3c1 (test-lib: allow negation of prerequisites, 2012-11-14) introduced negated predicates (e.g. "!MINGW,!CYGWIN"), we already had 5 test files that use NOT_MINGW (and a few MINGW) as prerequisites. Let's not add NOT_FOO and rewrite existing ones as !FOO for both MINGW and CYGWIN. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-13trace: disable additional trace output for unit testsLibravatar Karsten Blees1-0/+4
Some unit-tests use trace output to verify internal state, and unstable output such as timestamps and line numbers are not useful there. Disable additional trace output if GIT_TRACE_BARE is set. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-20Merge branch 'jc/test-lazy-prereq' (early part)Libravatar Junio C Hamano1-0/+8
* 'jc/test-lazy-prereq' (early part): t3419: drop unnecessary NOT_EXPENSIVE pseudo-prerequisite t3302: drop unnecessary NOT_EXPENSIVE pseudo-prerequisite t3302: do not chdir around in the primary test process t3302: coding style updates test: turn USR_BIN_TIME into a lazy prerequisite test: turn EXPENSIVE into a lazy prerequisite
2014-06-16Merge branch 'ib/test-selectively-run'Libravatar Junio C Hamano1-4/+115
Allow specifying only certain individual test pieces to be run using a range notation (e.g. "t1234-test.sh --run='1-4 6 8 9-'"). * ib/test-selectively-run: t0000-*.sh: fix the GIT_SKIP_TESTS sub-tests test-lib: '--run' to run only specific tests test-lib: tests skipped by GIT_SKIP_TESTS say so test-lib: document short options in t/README
2014-06-09test: turn USR_BIN_TIME into a lazy prerequisiteLibravatar Junio C Hamano1-0/+4
Two test scripts (t3302 and t3419) had copy & paste code to set USR_BIN_TIME prerequisite. Use the test_lazy_prereq helper to define them in the common t/test-lib.sh. Signed-off-by: Junio C Hamano <gitster@pobox.com>