fsck: check even zero-entry index files
commit8d3e7eac529b42319622692028b45670bdff8835
authorJeff King <peff@peff.net>
Sun, 26 Feb 2023 22:29:43 +0000 (26 17:29 -0500)
committerJunio C Hamano <gitster@pobox.com>
Mon, 27 Feb 2023 15:36:36 +0000 (27 07:36 -0800)
treee68d1b2546eb618ca8bbd73e0326c00865178ef7
parent592ec63b38ca7e2fb069ce1bf41b47a6f5a4ef8a
fsck: check even zero-entry index files

In fb64ca526a (fsck: check index files in all worktrees, 2023-02-24), we
swapped out a call to vanilla repo_read_index() for a series of
read_index_from() calls, one per worktree. The code for the latter was
copied from add_index_objects_to_pending(), which checks for a positive
return value from the index reading function, and we do the same here in
fsck now.

But this is probably the wrong thing. I had interpreted the check as
"don't operate on the index struct if there was an error". But in
reality, if there is an error then the index-reading code will simply
die (which admittedly is not great for fsck, but that is not a new
problem).

The return value here is actually the number of entries read. So it
makes sense for add_index_objects_to_pending() to ignore a zero-entry
index (there is nothing to add). But for fsck, we would still want to
check any extensions, etc (though presumably it is unlikely to have them
in an empty index, I don't think it's impossible).

So we should ignore the return value from read_index_from() entirely.
This matches the behavior before fb64ca526a, when we ignored the return
value from repo_read_index().

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fsck.c