summaryrefslogtreecommitdiff
path: root/cache.h
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-01-13 12:55:55 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-01-15 15:59:03 -0800
commit118e6cead47fafa17db12fdec9b997535f4f0fc6 (patch)
treeb3e6aecede2bd800478e118c7b5db97e9d1bc39a /cache.h
parentsha1_file: fix error message for alternate objects (diff)
downloadtgif-118e6cead47fafa17db12fdec9b997535f4f0fc6.tar.xz
t1450: test fsck of packed objects
The code paths in fsck for packed and loose objects are quite different, and it is not immediately obvious that the packed case behaves well. In particular: 1. The fsck_loose() function always returns "0" to tell the iterator to keep checking more objects. Whereas fsck_obj_buffer() (which handles packed objects) returns -1. This is OK, because the callback machinery for verify_pack() does not stop when it sees a non-zero return. 2. The fsck_loose() function sets the ERROR_OBJECT bit when fsck_obj() fails, whereas fsck_obj_buffer() sets it only when it sees a corrupt object. This turns out not to matter. We don't actually do anything with this bit except exit the program with a non-zero code, and that is handled already by the non-zero return from the function. So there are no bugs here, but it was certainly confusing to me. And we do not test either of the properties in t1450 (neither that a non-corruption error will caused a non-zero exit for a packed object, nor that we keep going after seeing the first error). Let's test both of those conditions, so that we'll notice if any of those assumptions becomes invalid. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'cache.h')
0 files changed, 0 insertions, 0 deletions