@leroysheep / MovieWebApp / commits / 3f4f64430a

t5608: mark >4GB tests as EXPENSIVE

Even with precomputed pack constants that reduced the helper's runtime from minutes to seconds, the >4GB clone tests still take 200-850 seconds across CI jobs. The bottleneck is no longer the pack generation but the clone operations themselves: transporting, unpacking, and indexing 4 GiB of data through unpack-objects and index-pack is inherently expensive. As Jeff King pointed out [1], t5608 alone takes 160 seconds on his laptop while the rest of the entire test suite finishes in under 90 seconds, and the test's disk footprint (4+ GiB source repo, then two clones) is problematic for developers who use RAM disks for their trash directories. Gate the >4GB tests on the EXPENSIVE prereq (which requires GIT_TEST_LONG to be set) in addition to SIZE_T_IS_64BIT, keeping them out of normal local test runs. [1] https://lore.kernel.org/git/20260501063805.GA2038915@coredump.intra.peff.net/ Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Johannes Schindelin committed May 8, 2026 at 08:16 UTC 3f4f64430a7abdae2f1019c5c16e05c7f287a145

1 file changed +3 -3

t/t5608-clone-2gb.sh

+3 -3

index af93302dde..4f8a95ddda 100755 --- a/t/t5608-clone-2gb.sh +++ b/t/t5608-clone-2gb.sh @@ -49,7 +49,7 @@ test_expect_success 'clone - with worktree, file:// protocol' ' ' -test_expect_success SIZE_T_IS_64BIT 'set up repo with >4GB object' ' +test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'set up repo with >4GB object' ' large_blob_size=$((4*1024*1024*1024+1)) && git init --bare 4gb-repo && head_oid=$(test-tool synthesize pack \ @@ -60,7 +60,7 @@ test_expect_success SIZE_T_IS_64BIT 'set up repo with >4GB object' ' git -C 4gb-repo symbolic-ref HEAD refs/heads/main ' -test_expect_success SIZE_T_IS_64BIT 'clone >4GB object via unpack-objects' ' +test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'clone >4GB object via unpack-objects' ' # The synthesized pack has five objects, so a large unpack limit keeps # fetch-pack on the unpack-objects path. git -c fetch.unpackLimit=100 clone --bare \ @@ -76,7 +76,7 @@ test_expect_success SIZE_T_IS_64BIT 'clone >4GB object via unpack-objects' ' test "$source_blob" = "$clone_blob" ' -test_expect_success SIZE_T_IS_64BIT 'clone with >4GB object via index-pack' ' +test_expect_success SIZE_T_IS_64BIT,EXPENSIVE 'clone with >4GB object via index-pack' ' # Force fetch-pack to hand the pack to index-pack instead. git -c fetch.unpackLimit=1 clone --bare \ "file://$(pwd)/4gb-repo" 4gb-clone-index &&