Re: `git gc` says "unable to read" but `git fsck` happy
- From
Jeff King <peff@peff.net>
- Date
- Mar 30, 2023, 18:17 UTC
- Message-ID
- <20230330181716.GA3286761@coredump.intra.peff.net>
- In-Reply-To
- <jwvfs9mz9n7.fsf-monnier+Inbox@gnu.org>
On Thu, Mar 30, 2023 at 09:01:39AM -0400, Stefan Monnier wrote:
Show 10 quoted lines
> > 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".
Show 9 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.
Hmm. I wouldn't expect that to happen specifically with this worktree thing, but of course many bets are off with power failures.
-Peff