On Tue, 19 Oct 2010, Uwe Kleine-König wrote: > Hi Jonathan, > > On Tue, Oct 19, 2010 at 01:39:25PM -0500, Jonathan Nieder wrote: > > Uwe Kleine-König wrote: > > > > > ukl@hostname:~/path1/linux-2.6$ git fetch ~/path2/linux-2.6 sectionmismatches > > > remote: Counting objects: 118, done. > > > remote: error: unable to find 40aaeb204dc04d3cf15c060133f65538b43b13b0 > > > remote: Compressing objects: 100% (83/83), done. > > > remote: fatal: unable to read 40aaeb204dc04d3cf15c060133f65538b43b13b0 > > > error: git upload-pack: git-pack-objects died with error. > > > fatal: git upload-pack: aborting due to possible repository corruption on the remote side. > > > > Sounds like alternates or workdir allowed gc to be overzealous, indeed. > > > > Could you: > > > > 1. Make a copy of the corrupted repo, just in case. > > 2. Explode all backs with "git unpack-objects" That's usually unnecessary. If the pack itself is corrupted, trying to unpack it all won't help. > I did: > > mv .git/objects/pack .git/objects/pack.bak > rm .git/objects/info/alternates > for p in .git/objects/pack.bak/*.pack ~/path1/linux-2.6/.git/objects/pack/*.pack; do > git unpack-objects < $p > done Ouch! You will end up with a multi-gigabyte repository, which will be abominably slow. > > 3. Identify the missing object, as explained in > > Documentation/howto/recover-corrupted-blob-object.txt? That's useful when you have only one corrupted object and you want to recreate it from raw material. But ideally you should simply find a pack that contains the problematic object in another repository and copy it with its index file into the broken repository. > and I'm running git-fsck --full now over night as it's bedtime here. Given that you exploded your repo into loose objects, it'll take _time_. Nicolas