'
+test_expect_success SIZE_T_IS_64BIT '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 \
+ --reachable-large "$large_blob_size" \
+ 4gb-repo/objects/pack/test.pack) &&
+ git -C 4gb-repo index-pack objects/pack/test.pack &&
+ git -C 4gb-repo update-ref refs/heads/main $head_oid &&
+ git -C 4gb-repo symbolic-ref HEAD refs/heads/main
+'
+
+test_expect_success SIZE_T_IS_64BIT '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 \
+ "file://$(pwd)/4gb-repo" 4gb-clone-unpack &&
+
+ # Verify the large blob survived the clone by comparing its OID
+ # between source and clone. We cannot use "cat-file -s" because
+ # object_info.sizep is still unsigned long, which truncates >4GB
+ # sizes on Windows. OID equality proves content integrity since
+ # the clone already verified checksums via index-pack/unpack-objects.
+ source_blob=$(git -C 4gb-repo rev-parse main^:file) &&
+ clone_blob=$(git -C 4gb-clone-unpack rev-parse main^:file) &&
+ test "$source_blob" = "$clone_blob"
+'
+
+test_expect_success SIZE_T_IS_64BIT '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 &&
+
+ source_blob=$(git -C 4gb-repo rev-parse main^:file) &&
+ clone_blob=$(git -C 4gb-clone-index rev-parse main^:file) &&
+ test "$source_blob" = "$clone_blob"
+'
+
test_done