git clone not working.

[Cesar Eduardo Barros]

Andy Green escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> 
> | Looks like we lost almost all the branches. We only have these ones
> | left: andy debug master stable
> 
> It's OK I have them all and will push them back up, I just stuck the
> critical ones back until now.
> 
> | Unfortunately, the reflog seems to be deleted together with the
> | corresponding ref; I'll probably make later a patch to git to avoid
> | that. I have a copy of all of them (as of a few days ago, but IIRC only
> | stable and andy has changed in the past few days) in the "origin" remote
> | of my cpufreq repository:
> 
> I just moved that dir out of the way rather than really deleted it so I
> have all these guys still.
> 
> What do you recommend, just cp them back to these dirs from the busted
> repo image?

They could either be on files at refs/heads/ or on the packed-refs file, 
making it a bit harder to cp (not much; you just have to copy both, and 
push your new refs again[1]). However, the missing objects (from the 
broken pack ae90d81e3c7e27be22a87e87e4e86f78bf2fcfcc and possibly other 
packs -- we don't know what else could be corrupted) are a bit harder to 
recover.

If you or someone else has a clone with the correct references (check 
them against git ls-remote --heads . on the broken repository), the 
easiest way is to push them all, and nothing else would need to be done.

The second easiest way would to recover would be to create a copy of the 
damaged repository, copy a set of working packs and loose objects from 
someone who has them (you could try downloading everything from 
http://repo.or.cz/r/linux-2.6/openmoko-kernel.git/objects/, which is 
updated hourly and doesn't seem to have been repacked yet[2]), remove 
the broken packs and/or objects (we already know of at least one)[3], 
and check the result with git fsck --full. If it works, copy the 
resulting set of objects and references to the new repository, copy the 
refs as above, and fsck the new repository (just to be sure); or as an 
alternative simply put the broken (now fixed) repository back in place.

The last step would be to run git update-server-info (since you skipped 
any hook which would run it).

After it's fixed, do a git fsck --full on _all_ the other repositories 
in that machine. git repositories shouldn't get corrupted that easily, 
and it almost always points to hardware problems. You could also either 
update git on the server to at least 1.6.0 or set pack.indexVersion to 2 
(the new default on 1.6.0) and do a full repack of everything; the 
resulting packs have extra protection against corruption, but are 
incompatible with git 1.4.4.4[4] or earlier when fetching over http 
(fetching over the native git protocol works, and git 1.4.4.5 also 
works; the error message is a very obscure "non-monotonic index" one).


[1] Or you can use git ls-remote --heads . on the broken repository and 
use git update-ref on the new repository to recreate each one by hand, 
which also updates the reflog.

[2] My own copy on my machine should be a little behind but hasn't been 
repacked for sure.

[3] Very recent versions of git should be able to skip the damaged 
objects within the pack and recover the rest while doing a full repack, 
so on them a full repack might be an alternative to removing the damaged 
packs and objects, but if it works it's simpler to remove them.

[4] Only Debian etch (the current stable) still has that old version. 
git 1.4.4.5 was made especially for them; the only change is the ability 
to read (but not write) the version 2 pack index.

-- 
Cesar Eduardo Barros
cesarb at cesarb.net
cesar.barros at gmail.com