On Tue, 31 Jul 2007, Denis Bueno wrote: > > I'm a new git user (actually a darcs convert) and am running into a weird > problem on a small and simple repository. The error I see is: > > git[14] > git clone /Volumes/work/scripts/ > Initialized empty Git repository in /tmp/git/scripts/.git/ > remote: Generating pack... > Done counting 80 objects. > remote: error: unable to unpack b28b949a1a3c8eb37ca6eefd024508fa8b253429 header > fatal: unable to get type of object b28b949a1a3c8eb37ca6error: git-upload-pack: git-pack-objects died with error. > fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. > remote: aborting due to possible repository corruption on the remote side. > fatal: early EOF > fatal: index-pack died with error code 128 > fetch-pack from '/Volumes/work/scripts/.git' failed. Well, it says so, but the most likely issue really is that there is "corruption on the remote side". Please do cd /Volumes/work/scripts git fsck --full which I would guess will almost certainly talk about some kind of problems with that object "b28b949a1a3c8eb37ca6eefd024508fa8b253429". And possibly more. The "unable to unpack .. header" problem would at a guess be a totally corrupted loose object. You should have a file named .git/objects/b2/8b949a1a3c8eb37ca6eefd024508fa8b253429 and it sounds like that file is corrupt. So far, apart from a CRLF conversion bug (that you wouldn't have triggered on OS X anyway), I think every single time we've seen that, it's been a real disk or memory corruption. Trying to restore corrupt objects can be quite hard, since git stores them in a compressed format, and so git single-bit errors are very detectable (that's kind of the point of having cryptographically secure hashes!), but they are very much not fixable, unless you can find the original data that *resulted* in that object some way (in another clone of the git repository, or in a backup). There are certainly ways to figure out what that object _should_ be, though. For example, if that object is the only corrupted entry, and it's a blob (ie pure data object), what you can generally do is still use the repo (as long as you avoid that particular blob), and do things like git log --raw -r --no-abbrev and you'll see the git history with all blobs named with their SHA1's. Then you can just search for that b28b949.. name, and you'll see exactly which file (in which version) it was, and if you can just find a backup of that file (or re-create it *exactly* from previous versions and your memory of it), you can re-generate the git object and thus save your repository. Of course, a much easier option tends to be to just have a backup repository that has that object in it, and then you can literally just copy that b28b949 object over. In short: git basically guarantees that it will *find* all corruption, but it doesn't do backups for you. Backups are easy to do (cloning), and git also makes incremental backups trivial (ie just do "git fetch" or "git push"), but git won't do backups for you unless you ask for them that way. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
