git clone not working.
Cesar Eduardo Barros
cesarb at cesarb.net
Thu Sep 4 13:51:59 CEST 2008
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
More information about the openmoko-kernel
mailing list