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

[Jeff King <peff@peff.net>]

On Thu, Mar 30, 2023 at 09:01:39AM -0400, Stefan Monnier wrote:

> > 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.

If you try "git fsck" from the tip of master, it should identify the
worktree index that is the source of the problem, I think. You might
need to pass "--name-objects".

> >      (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.

Hmm. I wouldn't expect that to happen specifically with this worktree
thing, but of course many bets are off with power failures.

-Peff