When using SHA-1, the existing value of the byte we use is 0x13, so writing the byte 0x07 serves to corrupt the test and verify that we detect corruption. However, when we use SHA-256, the value at that offset is already 0x07, so our "corruption" doesn't work and the test fails to detect it. To provide a value that is truly out of range, let's use 0xff, which is not likely to be a valid value as the high byte of a two-byte offset in a multi-pack index this small. Signed-off-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> --- t/t5319-multi-pack-index.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh index cd2f87be6a..464bb68e89 100755 --- a/t/t5319-multi-pack-index.sh +++ b/t/t5319-multi-pack-index.sh @@ -304,12 +304,12 @@ test_expect_success 'verify incorrect pack-int-id' ' ' test_expect_success 'verify incorrect offset' ' - corrupt_midx_and_verify $MIDX_BYTE_OFFSET "\07" $objdir \ + corrupt_midx_and_verify $MIDX_BYTE_OFFSET "\377" $objdir \ "incorrect object offset" ' test_expect_success 'git-fsck incorrect offset' ' - corrupt_midx_and_verify $MIDX_BYTE_OFFSET "\07" $objdir \ + corrupt_midx_and_verify $MIDX_BYTE_OFFSET "\377" $objdir \ "incorrect object offset" \ "git -c core.multipackindex=true fsck" '
