Re: `git gc` says "unable to read" but `git fsck` happy

From: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Mar 30, 2023, 13:01 UTC
Message-ID: <jwvfs9mz9n7.fsf-monnier+Inbox@gnu.org>
In-Reply-To: <20230329233735.GD2314218@coredump.intra.peff.net>

>> How come it can't read `f5e44b38fc8f7e15e5e6718090d05b09912254fa` during
>> "repack" while `git fsck` says everything is fine?
>
> Do you use separate worktrees?

Very much so, indeed!

> It sounds like it might be similar to this case:
>
>   https://lore.kernel.org/git/c6246ed5-bffc-7af9-1540-4e2071eff5dc@kdbg.org/

That's sounds exactly right. I was actually preparing to file a separate bug report because of a similar problem I had identified where a worktree's `index` caused a similar problem (`git fsck` happy but `git gc` fails) except it was found much earlier in `git gc`, causing a "bad object" error almost right away.

> If so, there are patches in the current "master" (but not in a released
> version yet) that fix fsck to detect this.

Good, thanks.

Show 8 quoted lines

>> More importantly: how do I diagnose this further and fix it?
>
> If it is the same problem (which would be a blob or maybe cached tree
> missing in one of the worktree's index files), then probably you'd
> either:
>
>   1. Accept the loss and blow away that worktree's index file (or
>      perhaps even the whole worktree, and just recreate it).

Hmm... the problem is "that": I have about a hundred worktrees for this repository. But yes, I can just throw away all those `index` files, I guess.

Show 5 quoted lines

>      (assuming that the file itself is still hanging around).
> The original corruption bug itself (gc not taking into account worktree
> index files) has been fixed for a while, so the theory is that this can
> be lingering corruption from a repack by an older version of Git. But if
> you have evidence to the contrary, we'd like to hear that, too. ;)

My suspicion is that the origin of the broken state is elsewhere (maybe a power failure?) because the problem appeared "simultaneously" (a few days apart, really) for two different repositories.

> I don't think --aggressive would help at all. In theory --prune=now
> might, but I think even that won't help if the problem is that the
> object is referenced in an index file.

Indeed, I had also tried `--prune=now` and it did not help. Thanks,

        Stefan