git/t/Makefile, branch v2.25.3

t/Makefile: add machinery to check correctness of chainlint.sed

2018-07-17T16:15:14Z

The --chain-lint option uses heuristics and knowledge of shell syntax to detect broken &&-chains in subshells by pure textual inspection. Although the heuristics work well, they are still best-guesses and future changes could accidentally break assumptions upon which they are based. To protect against this possibility, tests checking correctness of the linter itself will be added. As preparation, add a new makefile "check-chainlint" target and associated machinery. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

t/Makefile: introduce TEST_SHELL_PATH

2017-12-08T17:03:38Z

You may want to run the test suite with a different shell than you use to build Git. For instance, you may build with SHELL_PATH=/bin/sh (because it's faster, or it's what you expect to exist on systems where the build will be used) but want to run the test suite with bash (e.g., since that allows using "-x" reliably across the whole test suite). There's currently no good way to do this. You might think that doing two separate make invocations, like: make && make -C t SHELL_PATH=/bin/bash would work. And it _almost_ does. The second make will see our bash SHELL_PATH, and we'll use that to run the individual test scripts (or tell prove to use it to do so). So far so good. But this breaks down when "--tee" or "--verbose-log" is used. Those options cause the test script to actually re-exec itself using $SHELL_PATH. But wait, wouldn't our second make invocation have set SHELL_PATH correctly in the environment? Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we built during the first "make". And that overrides the environment, giving us the original SHELL_PATH again. Let's introduce a new variable that lets you specify a specific shell to be run for the test scripts. Note that we have to touch both the main and t/ Makefiles, since we have to record it in GIT-BUILD-OPTIONS in one, and use it in the latter. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t/Makefile: add a rule to re-run previously-failed tests

2017-01-27T18:53:40Z

This patch automates the process of determining which tests failed previously and re-running them. While developing patch series, it is a good practice to run the test suite from time to time, just to make sure that obvious bugs are caught early. With complex patch series, it is common to run `make -j15 -k test`, i.e. run the tests in parallel and *not* stop at the first failing test but continue. This has the advantage of identifying possibly multiple problems in one big test run. It is particularly important to reduce the turn-around time thusly on Windows, where the test suite spends 45 minutes on the computer on which this patch was developed. It is the most convenient way to determine which tests failed after running the entire test suite, in parallel, to look for left-over "trash directory.t*" subdirectories in the t/ subdirectory. However, those directories might live outside t/ when overridden using the --root= option, to which the Makefile has no access. The next best method is to grep explicitly for failed tests in the test-results/ directory, which the Makefile *can* access. Please note that the often-recommended `prove` tool requires Perl, and that opens a whole new can of worms on Windows. As no native Windows Perl comes with Subversion bindings, we have to use a Perl in Git for Windows that uses the POSIX emulation layer named MSYS2 (which is a portable version of Cygwin). When using this emulation layer under stress, e.g. when running massively-parallel tests, unexplicable crashes occur quite frequently, and instead of having a solution to the original problem, the developer now has an additional, quite huge problem. For that reason, this developer rejected `prove` as a solution and went with this patch instead. Signed-off-by: Johannes Schindelin Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

t/Makefile: ensure that paths are valid on platforms we care

2016-08-16T18:56:42Z

Some pathnames that are okay on ext4 and on HFS+ cannot be checked out on Windows. Tests that want to see operations on such paths on filesystems that support them must do so behind appropriate test prerequisites, and must not include them in the source tree (instead they should create them when they run). Otherwise, the source tree cannot even be checked out. Make sure that double-quotes, asterisk, colon, greater/less-than, question-mark, backslash, tab, vertical-bar, as well as any non-ASCII characters never appear in the pathnames with a new test-lint-* target as part of a `make test`. To that end, we call `git ls-files` (ensuring that the paths are quoted properly), relying on the fact that paths containing non-ASCII characters are quoted within double-quotes. In case that the source code does not actually live in a Git repository (e.g. when extracted from a .zip file), or that the `git` executable cannot be executed, we simply ignore the error for now; In that case, our trusty Continuous Integration will be the last line of defense and catch any problematic file name. Noticed when a topic wanted to add a pathname with '>' in it. A check like this will prevent a similar problems from happening in the future. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

tests: remove no-op full-svn-test target

2016-02-23T20:55:03Z

git-svn has not supported GIT_SVN_NO_OPTIMIZE_COMMITS for the "set-tree" sub-command in 9 years since commit 490f49ea5899 ("git-svn: remove optimized commit stuff for set-tree"). So remove this target and TSVN variable to avoid confusion. ref: http://mid.gmane.org/56C9B7B7.7030406@f2.dion.ne.jp Helped-by: Kazutoshi Satoda Signed-off-by: Eric Wong Signed-off-by: Junio C Hamano

t/Makefile: always test all lint targets when running tests

2014-07-10T20:04:42Z

Only the two targets "test-lint-duplicates" and "test-lint-executable" are currently executed when running the test target. This was done on purpose when the TEST_LINT variable was added in 81127d74 to avoid twisted shell scripting by developers only to avoid false positives that might result from the rather simple minded tests, e.g. test-lint-shell-syntax. But it looks like it might be better to include all lint tests to help developers to detect non portable shell constructs before the patch is sent to the list and reviewed there. Change the TEST_LINT variable to run all lint test unless the TEST_LINT variable is overridden. If we hit false positives more often than helping developers to avoid non-portable code (or add less accurate or slow tests later) we could still fall back to exclude them like 81127d74 proposed. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

t/Makefile: check helper scripts for non-portable shell commands too

2014-07-10T20:04:34Z

Currently only the "t[0-9][0-9][0-9][0-9]-*.sh" scripts are tested for shell incompatibilities using the check-non-portable-shell.pl script. This makes it easy to miss non-POSIX constructs added to one of the t/*lib*.sh helper scripts, as they aren't automatically detected. Fix that by adding a THELPERS variable containing all shell scripts that aren't tests and add these to the "test-lint-shell-syntax" target too. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

t/Makefile: stop setting GIT_CONFIG

2014-03-21T21:10:30Z

Once upon a time, the setting of GIT_CONFIG in the environment could affect how tests ran. Commit 9c3796f (Fix setting config variables with an alternative GIT_CONFIG, 2006-06-20) unconditionally set GIT_CONFIG in the Makefile when running tests to give us a known starting point. This is insufficient for running the tests outside of the Makefile, however, and 8565d2d (Make tests independent of global config files, 2007-02-15) later set GIT_CONFIG directly in test-lib.sh. At that point the Makefile setting was redundant, but we never removed it. Let's do so now. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/test-output'

2013-05-29T21:29:11Z

When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat inconsistently between the test framework and t/Makefile, and logic to summarize the results looked at a wrong place. * jk/test-output: t/Makefile: don't define TEST_RESULTS_DIRECTORY recursively test output: respect $TEST_OUTPUT_DIRECTORY t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY

t/Makefile: don't define TEST_RESULTS_DIRECTORY recursively

2013-05-06T15:20:28Z

Commit 54bb901 (t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY - 2013-04-26) incorrectly defined TEST_RESULTS_DIRECTORY relative to itself, when it should be relative to TEST_OUTPUT_DIRECTORY. Fix this. Signed-off-by: John Keeping Signed-off-by: Junio C Hamano