git/t/t0000-basic.sh, branch v2.29.2

Merge branch 'bc/sha-256-part-3'

2020-08-12T01:04:11Z

The final leg of SHA-256 transition. * bc/sha-256-part-3: (39 commits) t: remove test_oid_init in tests docs: add documentation for extensions.objectFormat ci: run tests with SHA-256 t: make SHA1 prerequisite depend on default hash t: allow testing different hash algorithms via environment t: add test_oid option to select hash algorithm repository: enable SHA-256 support by default setup: add support for reading extensions.objectformat bundle: add new version for use with SHA-256 builtin/verify-pack: implement an --object-format option http-fetch: set up git directory before parsing pack hashes t0410: mark test with SHA1 prerequisite t5308: make test work with SHA-256 t9700: make hash size independent t9500: ensure that algorithm info is preserved in config t9350: make hash size independent t9301: make hash size independent t9300: use $ZERO_OID instead of hard-coded object ID t9300: abstract away SHA-1-specific constants t8011: make hash size independent ...

t: remove test_oid_init in tests

2020-07-30T16:16:49Z

Now that we call test_oid_init in the setup for all test scripts, there's no point in calling it individually. Remove all of the places where we've done so to help keep tests tidy. Signed-off-by: brian m. carlson Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano

t: add test_oid option to select hash algorithm

2020-07-30T16:16:49Z

In some tests, we have data files which are written with a particular hash algorithm. Instead of keeping two copies of the test files, we can keep one, and translate the value on the fly. In order to do so, we'll need to read both the source algorithm and the current algorithm, so add an optional flag to the test_oid helper that lets us look up a value for a specified hash algorithm. This should not cause any conflicts with existing tests, since key arguments to test_oid are allowed to contains only shell identifier characters. Signed-off-by: brian m. carlson Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano

test-lib-functions: restrict test_must_fail usage

2020-07-07T22:47:16Z

In previous commits, we removed the usage of test_must_fail() for most commands except for a set of pre-approved commands. Since that's done, only allow test_must_fail() to run those pre-approved commands. Obviously, we should allow `git`. We allow `__git*` as some completion functions return an error code that comes from a git invocation. It's good to avoid using test_must_fail unnecessarily but it wouldn't hurt to err on the side of caution when we're potentially wrapping a git command (like in these cases). We also allow `test-tool` and `test-svn-fe` because these are helper commands that are written by us and we want to catch their failure. Finally, we allow `test_terminal` because `test_terminal` just wraps around git commands. Also, we cannot rewrite `test_must_fail test_terminal` as `test_terminal test_must_fail` because test_must_fail() is a shell function and as a result, it cannot be invoked from the test-terminal Perl script. We opted to explicitly list the above tools instead of using a catch-all such as `test[-_]*` because we want to be as restrictive as possible so that in the future, someone would not accidentally introduce an unrelated usage of test_must_fail() on an "unapproved" command. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

Merge branch 'cb/t0000-use-the-configured-shell'

2020-05-08T21:25:12Z

The basic test did not honor $TEST_SHELL_PATH setting, which has been corrected. * cb/t0000-use-the-configured-shell: t/t0000-basic: make sure subtests also use TEST_SHELL_PATH

t/t0000-basic: make sure subtests also use TEST_SHELL_PATH

2020-05-07T20:01:32Z

3f824e91c8 (t/Makefile: introduce TEST_SHELL_PATH, 2017-12-08) allows for setting a shell for running the tests, but the generated subtests weren't updated. Correct that and while at it update it to use write_script. Signed-off-by: Carlo Marcelo Arenas Belón Acked-by: Jeff King Signed-off-by: Junio C Hamano

t0000: disable GIT_TEST_FAIL_PREREQS in sub-tests

2020-04-28T17:26:01Z

The test added by 477dcaddb6 (tests: do not let lazy prereqs inside `test_expect_*` turn off tracing, 2020-03-26) runs a sub-test script that traces a test with a lazy prereq, like: test_have_prereq LAZY && echo trace That won't work if GIT_TEST_FAIL_PREREQS is set in the environment, because our have_prereq will report failure, and we won't run the echo at all. We could work around this by avoiding the &&-chain, but we can fix this and any future tests at once by unsetting that variable for our sub-tests. These are meant to be controlled environments where we test the test-suite itself; the outer test snippet should be in charge of the sub-test environment, not whatever mode the user happens to be running in. Reported-by: Son Luong Ngoc Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

tests: do not let lazy prereqs inside `test_expect_*` turn off tracing

2020-03-26T20:36:54Z

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 Signed-off-by: Junio C Hamano

Merge branch 'dl/test-must-fail-fixes'

2020-02-05T22:34:57Z

Test clean-up. * dl/test-must-fail-fixes: t1507: inline full_name() t1507: run commands within test_expect_success t1507: stop losing return codes of git commands t1501: remove use of `test_might_fail cp` t1409: use test_path_is_missing() t1409: let sed open its own input file t1307: reorder `nongit test_must_fail` t1306: convert `test_might_fail rm` to `rm -f` t0020: use ! check_packed_refs_marked t0020: don't use `test_must_fail has_cr` t0003: don't use `test_must_fail attr_check` t0003: use test_must_be_empty() t0003: use named parameters in attr_check() t0000: replace test_must_fail with run_sub_test_lib_test_err() t/lib-git-p4: use test_path_is_missing()

t0000: replace test_must_fail with run_sub_test_lib_test_err()

2019-12-20T19:30:44Z

The test_must_fail function should only be used for git commands since we should assume that external commands work sanely. We use test_must_fail to test run_sub_test_lib_test() but that function does not invoke any git commands internally. Even better, we have a function that's exactly meant to be used when we expect to have a failing test suite: run_sub_test_lib_test_err()! Replace `test_must_fail run_sub_test_lib_test` with `run_sub_test_lib_test_err`. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano