Jeff King <peff@xxxxxxxx> writes: > 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). Good thinking. Not all extensions record what needs to be fed to the reachability machinery for fsck, but resolve-undo wants to record object names that used to be in the directory (at higher stages) when they are removed, so I think it is entirely possible for an index with no entries to have index extensions that fsck needs to pay attention to. > 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(). Good. Thanks. > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > On top of jk/fsck-indices-in-worktrees. > > builtin/fsck.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/builtin/fsck.c b/builtin/fsck.c > index 1b032eebb1..64614b43b2 100644 > --- a/builtin/fsck.c > +++ b/builtin/fsck.c > @@ -1007,9 +1007,8 @@ int cmd_fsck(int argc, const char **argv, const char *prefix) > * while we're examining the index. > */ > path = xstrdup(worktree_git_path(wt, "index")); > - if (read_index_from(&istate, path, > - get_worktree_git_dir(wt)) > 0) > - fsck_index(&istate, path, wt->is_current); > + read_index_from(&istate, path, get_worktree_git_dir(wt)); > + fsck_index(&istate, path, wt->is_current); > discard_index(&istate); > free(path); > }
