]> git.ipfire.org Git - thirdparty/git.git/commit
tests: do not let lazy prereqs inside `test_expect_*` turn off tracing
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Thu, 26 Mar 2020 15:35:26 +0000 (15:35 +0000)
committerJunio C Hamano <gitster@pobox.com>
Thu, 26 Mar 2020 20:36:54 +0000 (13:36 -0700)
commit477dcaddb6dceb0fc5b5064edef460d9d226386e
tree6a764dad72d199478b0c4ab29b9738ddba278043
parent975f45b6aa8161ad63ecaa4364a1f49c074de70c
tests: do not let lazy prereqs inside `test_expect_*` turn off tracing

The `test_expect_*` functions use `test_eval_` and so does
`test_run_lazy_prereq_`. If tracing is enabled via the `-x` option,
`test_eval_` turns on tracing while evaluating the code block, and turns
it off directly after it.

This is unwanted for nested invocations.

One somewhat surprising example of this is when running a test that
calls `test_i18ngrep`: that function requires the `C_LOCALE_OUTPUT`
prereq, and that prereq is a lazy one, so it is evaluated via
`test_eval_`, the command tracing is turned off, and the test case
continues to run _without tracing the commands_.

Another somewhat surprising example is when one lazy prereq depends on
another lazy prereq: the former will call `test_have_prereq` with the
latter one, which in turn calls `test_eval_` and -- you guessed it --
tracing (if enabled) will be turned off _before_ returning to evaluating
the other lazy prereq.

As we will introduce just such a scenario with the GPG, GPGSM and
RFC1991 prereqs, let's fix that by introducing a variable that keeps
track of the current trace level: nested `test_eval_` calls will
increment and then decrement the level, and only when it reaches 0, the
tracing will _actually_ be turned off.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t0000-basic.sh
t/test-lib.sh