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

Merge branch 'bc/sha1-256-interop-02'

2026-03-12T17:56:02Z

The code to maintain mapping between object names in multiple hash functions is being added, written in Rust. * bc/sha1-256-interop-02: object-file-convert: always make sure object ID algo is valid rust: add a small wrapper around the hashfile code rust: add a new binary object map format rust: add functionality to hash an object rust: add a build.rs script for tests rust: fix linking binaries with cargo hash: expose hash context functions to Rust write-or-die: add an fsync component for the object map csum-file: define hashwrite's count as a uint32_t rust: add additional helpers for ObjectID hash: add a function to look up hash algo structs rust: add a hash algorithm abstraction rust: add a ObjectID struct hash: use uint32_t for object_id algorithm conversion: don't crash when no destination algo repository: require Rust support for interoperability

Merge branch 'ps/maintenance-geometric-default'

2026-03-04T18:53:01Z

"git maintenance" starts using the "geometric" strategy by default. * ps/maintenance-geometric-default: builtin/maintenance: use "geometric" strategy by default t7900: prepare for switch of the default strategy t6500: explicitly use "gc" strategy t5510: explicitly use "gc" strategy t5400: explicitly use "gc" strategy t34xx: don't expire reflogs where it matters t: disable maintenance where we verify object database structure t: fix races caused by background maintenance

Merge branch 'ps/tests-wo-iconv-fixes'

2026-02-27T23:11:53Z

Some tests assumed "iconv" is available without honoring ICONV prerequisite, which has been corrected. * ps/tests-wo-iconv-fixes: t6006: don't use iconv(1) without ICONV prereq t5550: add ICONV prereq to tests that use "$HTTPD_URL/error" t4205: improve handling of ICONV prerequisite t40xx: don't use iconv(1) without ICONV prereq t: don't set ICONV prereq when iconv(1) is missing

t: fix races caused by background maintenance

2026-02-24T15:33:19Z

Many Git commands spawn git-maintenance(1) to optimize the repository in the background. By default, performing the maintenance is for most of the part asynchronous: we fork the executable and then continue with the rest of our business logic. This is working as expected for our users, but this behaviour is somewhat problematic for our test suite as this is inherently racy. We have many tests that verify the on-disk state of repositories, and those tests may easily race with our background maintenance. In a similar fashion, we may end up with processes that "leak" out of a current test case. Until now this tends to not be much of a problem. Our maintenance uses git-gc(1) by default, which knows to bail out in case there aren't either too many packfiles or too many loose objects. So even if other data structures would need to be optimized, we won't do so unless the object database also needs optimizations. This is about to change though, as a subsequent commit will switch to the "geometric" maintenance strategy as a default. The consequence is that we will run required optimizations even if the object database is well-optimized. And this uncovers races between our test suite and background maintenance all over the place. Disabling maintenance outright in our test suite is not really an option, as it would result in significant divergence from the "real world" and reduce our test coverage. But we've got an alternative up our sleeves: we can ensure that garbage collection runs synchronously by overriding the "maintenance.autoDetach" configuration. Of course that also diverges from the real world, as we now stop testing that background maintenance interacts in a benign way with normal Git commands. But on the other hand this ensures that the maintenance itself does not for example lead to data loss in a more reproducible way. Another concern is that this would make execution of the test suite much slower. But a quick benchmark on my machine demonstrates that this does not seem to be the case: Benchmark 1: meson test (revision = HEAD~) Time (mean ± σ): 131.182 s ± 1.293 s [User: 853.737 s, System: 1160.479 s] Range (min … max): 130.001 s … 132.563 s 3 runs Benchmark 2: meson test (revision = HEAD) Time (mean ± σ): 129.554 s ± 0.507 s [User: 849.040 s, System: 1152.664 s] Range (min … max): 129.000 s … 129.994 s 3 runs Summary meson test (revision = HEAD) ran 1.01 ± 0.01 times faster than meson test (revision = HEAD~) Funny enough, it even seems as if this speeds up test execution ever so slightly, but that may just as well be noise. Introduce a new `GIT_TEST_MAINT_AUTO_DETACH` environment variable that allows us to override the auto-detach behaviour and set that variable in our tests. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

t: don't set ICONV prereq when iconv(1) is missing

2026-02-20T15:52:26Z

We've got a couple of tests that exercise Git with different encodings, typically around commit messages. All of these tests depend on the ICONV prerequisite, which is set when Git was built with support for iconv. Many of those tests also end up using the iconv(1) executable to reencode text. But while tests can rely on the fact that Git does have support for iconv, they cannot assume that the iconv(1) executable exists. The consequence is thus that tests will break in case Git is built with iconv, but the executable doesn't exist. In fact, some of the tests even use the iconv(1) executable unconditionally, regardless of whether or not the ICONV prerequisite is set. Git for Windows has recently (unintentionally) shipped a change where the iconv(1) binary is not getting installed anymore [1]. And as we use Git for Windows directly in MSVC+Meson jobs in GitLab CI this has caused such tests to break. The missing iconv(1) binary is considered a bug that will be fixed in Git for Windows. But regardless of that it makes sense to not assume the binary to always exist so that our test suite passes on platforms that don't have iconv at all. Extend the ICONV prerequisite so that we know to skip tests in case the iconv(1) binary doesn't exist. We'll adapt tests that are currently broken in subsequent commits. [1]: https://github.com/git-for-windows/git/issues/6083 Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

repository: require Rust support for interoperability

2026-02-08T01:41:00Z

We'll be implementing some of our interoperability code, like the loose object map, in Rust. While the code currently compiles with the old loose object map format, which is written entirely in C, we'll soon replace that with the Rust-based implementation. Require the use of Rust for compatibility mode and die if it is not supported. Because the repo argument is not used when Rust is missing, cast it to void to silence the compiler warning, which we do not care about. Add a prerequisite in our tests, RUST, that checks if Rust functionality is available and use it in the tests that handle interoperability. This is technically a regression in functionality compared to our existing state, but pack index v3 is not yet implemented and thus the functionality is mostly quite broken, which is why we've recently marked this functionality as experimental. We don't believe anyone is getting useful use out of the interoperability code in its current state, so no actual users should be negatively impacted by this change. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'jk/asan-bonanza'

2025-12-01T02:31:41Z

Various issues detected by Asan have been corrected. * jk/asan-bonanza: t: enable ASan's strict_string_checks option fsck: avoid parse_timestamp() on buffer that isn't NUL-terminated fsck: remove redundant date timestamp check fsck: avoid strcspn() in fsck_ident() fsck: assert newline presence in fsck_ident() cache-tree: avoid strtol() on non-string buffer Makefile: turn on NO_MMAP when building with ASan pack-bitmap: handle name-hash lookups in incremental bitmaps compat/mmap: mark unused argument in git_munmap()

t: enable ASan's strict_string_checks option

2025-11-18T17:36:12Z

ASan has an option to enable strict string checking, where any pointer passed to a function that expects a NUL-terminated string will be checked for that NUL termination. This can sometimes produce false positives. E.g., it is not wrong to pass a buffer with { '1', '2', '\n' } into strtoul(). Even though it is not NUL-terminated, it will stop at the newline. But in trying it out, it identified two problematic spots in our test suite (which have now been adjusted): 1. The strtol() parsing in cache-tree.c was a real potential problem, which would have been very hard to find otherwise (since it required constructing a very specific broken index file). 2. The use of string functions in fsck_ident() were false positives, because we knew that there was always a trailing newline which would stop the functions from reading off the end of the buffer. But the reasoning behind that is somewhat fragile, and silencing those complaints made the code easier to reason about. So even though this did not find any earth-shattering bugs, and even had a few false positives, I'm sufficiently convinced that its complaints are more helpful than hurtful. Let's turn it on by default (since the test suite now runs cleanly with it) and see if it ever turns up any other instances. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'bc/sha1-256-interop-01'

2025-10-22T18:38:58Z

The beginning of SHA1-SHA256 interoperability work. * bc/sha1-256-interop-01: t1010: use BROKEN_OBJECTS prerequisite t: allow specifying compatibility hash fsck: consider gpgsig headers expected in tags rev-parse: allow printing compatibility hash docs: add documentation for loose objects docs: improve ambiguous areas of pack format documentation docs: reflect actual double signature for tags docs: update offset order for pack index v3 docs: update pack index v3 format

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