In t4141 we generate a patch that is roughly 1GB in size to verify that
git-apply(1) indeed rejects that patch. We generate that patch by
prepending a patch header and then executing `test-tool genzeros`
without a limit. This causes us to print infinitely many zeros, and we
limit the overall amount of generated bytes via `test_copy_bytes`.
This test setup is extremely expensive, as `test_copy_bytes` is
implemented via `dd ibs=1 count="$1"`, which copies data one byte at a
time. So as we write 1GB of data, we end up doing 1 billion reads and
writes. This naturally takes a while: it takes 6 minutes on my system,
and around 40 minutes in some CI jobs!
We can do much better though, as genzeros already knows to handle an
optional limit of how much data it is supposed to write, which allows us
to remove the call to `test_copy_bytes`. Furthermore, it has already
been optimized to generate the data fast.
And indeed, doing this conversion drops the test execution to less than
a second on my machine. That means that in theory it becomes feasible to
drop the EXPENSIVE prerequisite now. But git-apply(1) still soaks up 1GB
of data into memory, which may count as being expensive. Consequently,
we keep the prerequisite intact.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
. ./test-lib.sh
test_expect_success EXPENSIVE 'git apply rejects patches that are too large' '
- sz=$((1024 * 1024 * 1023)) &&
{
cat <<-\EOF &&
diff --git a/file b/file
+++ b/file
@@ -0,0 +1 @@
EOF
- test-tool genzeros
- } | test_copy_bytes $sz | test_must_fail git apply 2>err &&
+ test-tool genzeros $((1024 * 1024 * 1023))
+ } | test_must_fail git apply 2>err &&
grep "patch too large" err
'