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@xxxxxxxx> --- I only today figured out the GIT_TRACE=4 trick. Perhaps everybody else did long ago, and I am just slow. :) My first inclination was to mention it in the warning message below, but I cannot see a downside to automatically redirecting it. Even outside of test_expect_* we have the "4>&2" redirection, so we should hit even badly written scripts which call git outside of that environment. t/test-lib.sh | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index f4ba3ff..7dd4b4d 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -152,10 +152,7 @@ unset UNZIP case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in 1|2|true) - echo "* warning: Some tests will not work if GIT_TRACE" \ - "is set as to trace on STDERR ! *" - echo "* warning: Please set GIT_TRACE to something" \ - "other than 1, 2 or true ! *" + GIT_TRACE=4 ;; esac -- 2.3.2.472.geadab3c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html