Re: Git clone error

[Linus Torvalds <torvalds@linux-foundation.org>]

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