t1450: test fsck of packed objects
commit118e6cead47fafa17db12fdec9b997535f4f0fc6
authorJeff King <peff@peff.net>
Fri, 13 Jan 2017 17:55:55 +0000 (13 12:55 -0500)
committerJunio C Hamano <gitster@pobox.com>
Sun, 15 Jan 2017 23:59:03 +0000 (15 15:59 -0800)
treeb3e6aecede2bd800478e118c7b5db97e9d1bc39a
parent771e7d578ee93753f5ac0ed346effd0af3d5a4b4
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>
t/t1450-fsck.sh