git/t/test-lib-functions.sh, branch main

t: add matching negative attributes to test_decode_color

2026-03-23T14:42:27Z

Most of the ANSI color attributes have an "off" variant. We don't use these yet in our test suite, so we never bothered to decode them. Add the ones that match the attributes we encode so we can make use of them. There are even more attributes not covered on the positive side, so this is meant to be useful but not all-inclusive. Note that "nobold" and "nodim" are the same code, so I've decoded this as "normal intensity". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'js/test-func-comment-fix'

2025-12-30T03:58:21Z

Comment fix. * js/test-func-comment-fix: test_detect_ref_format: fix comment

test_detect_ref_format: fix comment

2025-12-19T03:49:51Z

When 58aaf59133b (t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar, 2023-12-29) copy-edited the `test_detect_hash` function, the code comment was accidentally left unchanged. Let's adjust it. Noticed-by: Matthew John Cheetham Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

t: allow specifying compatibility hash

2025-10-10T00:46:15Z

We want to specify a compatibility hash for testing interactions for SHA-256 repositories where we have SHA-1 compatibility enabled. Allow the user to specify this scenario in the test suite by setting GIT_TEST_DEFAULT_HASH to "sha256:sha1". Note that this will get passed into GIT_DEFAULT_HASH, which Git itself does not presently support. However, we will support this in a future commit. Since we'll now want to know the value for a specific version, let's add the ability to specify either the storage hash (in this case, SHA-256) or the compatibility hash (SHA-1). We use a different value for the compatibility hash that will be enabled for all repositories (test_repo_compat_hash_algo) versus the one that is used individually in some tests (test_compat_hash_algo), since we want to still run those individual tests without requiring that the testsuite be run fully in a compatibility mode. In some cases, we'll need to adjust our test suite to work in a proper way with a compatibility hash. For example, in such a case, we'll only use pack index v3, since v1 and v2 lack support for multiple algorithms. Since we won't want to write those older formats, we'll need to skip tests that do so. Let's add a COMPAT_HASH prerequisite for this purpose. Finally, in this scenario, we can no longer rely on having broken objects work since we lack compatibility mappings to rewrite objects in the repository. Add a prerequisite, BROKEN_OBJECTS, that we define in terms of COMPAT_HASH and checks to see if creating deliberately broken objects is possible, so that we can disable these tests if not. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'bc/use-sha256-by-default-in-3.0'

2025-07-21T16:14:25Z

Prepare to flip the default hash function to SHA-256. * bc/use-sha256-by-default-in-3.0: Enable SHA-256 by default in breaking changes mode help: add a build option for default hash t5300: choose the built-in hash outside of a repo t4042: choose the built-in hash outside of a repo t1007: choose the built-in hash outside of a repo t: default to compile-time default hash if not set setup: use the default algorithm to initialize repo format Use legacy hash for legacy formats builtin: use default hash when outside a repository hash: add a constant for the legacy hash algorithm hash: add a constant for the default hash algorithm

t: default to compile-time default hash if not set

2025-07-01T21:58:25Z

Right now, the default compile-time hash is SHA-1. However, in the future, this might change and it would be helpful to gracefully handle this case in our testsuite. To avoid making these assumptions, let's introduce a variable that contains the built-in default hash and use it in our setup code as the fallback value if no hash was explicitly set. For now, this is always SHA-1, but in a future commit, we'll allow adjusting this and the variable will be more useful. To allow us to make our tests more robust, allow test_oid to take the --hash=builtin option to specify this hash, whatever it is. Additionally, add a DEFAULT_HASH_ALGORITHM prerequisite to check for the compile-time hash. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

test-lib: teach test_seq the -f option

2025-06-24T13:34:25Z

The "seq" tool has a "-f" option to produce printf-style formatted lines. Let's teach our test_seq helper the same trick. This lets us get rid of some shell loops in test snippets (which are particularly verbose in our test suite because we have to "|| return 1" to keep the &&-chain going). This converts a few call-sites I found by grepping around the test suite. A few notes on these: - In "seq", the format specifier is a "%g" float. Since test_seq only supports integers, I've kept the more natural "%d" (which is what these call sites were using already). - Like "seq", test_seq automatically adds a newline to the specified format. This is what all callers are doing already except for t0021, but there we do not care about the exact format. We are just trying to printf a large number of bytes to a file. It's not worth complicating other callers or adding an option to avoid the newline in that caller. - Most conversions are just replacing a shell loop (which does get rid of an extra fork, since $() requires a subshell). In t0612 we can replace an awk invocation, which I think makes the end result more readable, as there's less quoting. - In t7422 we can replace one loop, but sadly we have to leave the loop directly above it. This is because that earlier loop wants to include the seq value twice in the output, which test_seq does not support (nor does regular seq). If you run: test_seq -f "foo-%d %d" 10 the second "%d" will always be the empty string. You might naively think that test_seq could add some extra arguments, like: # 3 ought to be enough for anyone... printf "$fmt\n" "$i "$i" $i" but that just triggers printf to format multiple lines, one per extra set of arguments. So we'd have to actually parse the format string, figure out how many "%" placeholders are there, and then feed it that many instances of the sequence number. The complexity isn't worth it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ps/test-wo-perl-prereq'

2025-04-16T20:54:20Z

"make test" used to have a hard dependency on (basic) Perl; tests have been rewritten help environment with NO_PERL test the build as much as possible. * ps/test-wo-perl-prereq: t5703: refactor test to not depend on Perl t5316: refactor `max_chain()` to not depend on Perl t0210: refactor trace2 scrubbing to not use Perl t0021: refactor `generate_random_characters()` to not depend on Perl t/lib-httpd: refactor "one-time-perl" CGI script to not depend on Perl t/lib-t6000: refactor `name_from_description()` to not depend on Perl t/lib-gpg: refactor `sanitize_pgp()` to not depend on Perl t: refactor tests depending on Perl for textconv scripts t: refactor tests depending on Perl to print data t: refactor tests depending on Perl substitution operator t: refactor tests depending on Perl transliteration operator Makefile: stop requiring Perl when running tests meson: stop requiring Perl when tests are enabled t: adapt existing PERL prerequisites t: introduce PERL_TEST_HELPERS prerequisite t: adapt `test_readlink()` to not use Perl t: adapt `test_copy_bytes()` to not use Perl t: adapt character translation helpers to not use Perl t: refactor environment sanitization to not use Perl t: skip chain lint when PERL_PATH is unset

t: adapt `test_readlink()` to not use Perl

2025-04-07T21:47:37Z

The `test_readlink()` helper function reads a symbolic link and returns the path it is pointing to. It is thus equivalent to the readlink(1) utility, which isn't available on all supported platforms. As such, it is implemented using Perl so that we can use it even on platforms where the shell utility isn't available. While using readlink(1) is not an option, what we can do is to implement the logic ourselves in our test-tool. Do so, which allows a bunch of tests to pass when Perl is not available. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

t: adapt `test_copy_bytes()` to not use Perl

2025-04-07T21:47:37Z

The `test_copy_bytes()` helper function copies up to N bytes from stdin to stdout. This is implemented using Perl, but it can be trivially adapted to instead use dd(1). Refactor the helper accordingly, which allows a bunch of tests to pass when Perl is not available. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano