I vaguely recall there was a recent threaad discussing fsck and normal codepath doing different checks. Does this look similar to what you have? (sorry, I am running out of gas tonight to dig deeply myself). https://lore.kernel.org/git/20230330181716.GA3286761@xxxxxxxxxxxxxxxxxxxxxxx/ Andreas Schwab <schwab@xxxxxxx> writes: > $ git count-objects -v -H > count: 2177 > size: 17.75 MiB > in-pack: 878690 > packs: 46 > size-pack: 279.84 MiB > prune-packable: 0 > garbage: 0 > size-garbage: 0 bytes > $ git gc > Enumerating objects: 866036, done. > Counting objects: 100% (866036/866036), done. > Delta compression using up to 8 threads > Compressing objects: 100% (144924/144924), done. > fatal: unable to read e8524e0483c8e65746888368f77f83d7a955ea87 > fatal: failed to run repack > > How can I find out where the bad object is referenced to be able to get > rid of it? It is not part of the regular history, a re-clone of the > remote repository does not fetch it. git fsck --full --cache prints a > lot of dangling commits, but still does not complain. The error happens > about half way through writing out the new pack. > > The repository is more than 10 years old and in regular use all that > time, including a lot of rebasing. I have looked through all of the > reflogs, but couldn't find the object there either. git prune > --expire=now and git reflog expire --all --stale-fix > --expire-unreachable=all didn't help. > > Then I used the fresh clone to copy over all heads I know about, like > recreating the branches and replace refs, fetching all reflog entries. > That did not report any problems and git gc does not complain, but it > has about 14800 objects less. > > Any ideas?
