summaryrefslogtreecommitdiff
path: root/builtin/merge-recursive.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2021-11-16 16:38:50 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-11-18 14:35:08 -0800
commit152923b132d57e1dbd693a8cb9a8bc1827405674 (patch)
tree3e63a213c5a819f46c1a20050bb209cd7399d50e /builtin/merge-recursive.c
parentMerge branch 'vd/pthread-setspecific-g11-fix' into maint (diff)
downloadtgif-152923b132d57e1dbd693a8cb9a8bc1827405674.tar.xz
t5319: corrupt more bytes of the midx checksum
One of the tests in t5319 corrupts the checksum of the midx file by writing a single 0xff over the final byte, and then confirms that we detect the problem. This usually works fine, but would break if the actual checksum ended with that same byte already. It seems like this should happen in 1 out of 256 test runs, but it turns out to be less often in practice. The contents of the midx are mostly deterministic because it's based on the objects, and we remove most sources of randomness by setting GIT_COMMITTER_DATE, etc. However, there's still some randomness: some objects are duplicated between packs, and the midx must decide which to use, which can be based on timing. So very occasionally we can end up with a real 0xff byte, and the test fails. The most robust fix would be to read out the final byte and then change it to something else (e.g., adding 1 mod 256). But that's awkward to do in shell. Let's just blindly corrupt 10 bytes instead of 1, which reduces our chances of an accidental noop to 1 in 2^80. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/merge-recursive.c')
0 files changed, 0 insertions, 0 deletions