0

It seems that some files got corrupted on my remote git server and I'm getting the following error when I try to clone the repo to a new system.

remote: error: Could not read c168e82dd62c0cdbf3ea7c3be3a84218a12c8a03
remote: fatal: Failed to traverse parents of commit 02d8c9217333d89afd61da1788fa82329b692610
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

When I run a git fsck --name-objects:

broken link from  commit 02d8c9217333d89afd61da1788fa82329b692610 (~17)
              to  commit c168e82dd62c0cdbf3ea7c3be3a84218a12c8a03 (~18)

I have a local copy of the repo that doesnt have the error, is there a way to just copy the missing or corrupted files?

torek
  • 448,244
  • 59
  • 642
  • 775
Leandros Sardinas
  • 33
  • 2

2 Answers2

0

It's not so much files that are missing or corrupt, it's that the internal object (commit 02d8c9217333d89afd61da1788fa82329b692610 on the server) refers to another internal object (c168e82dd62c0cdbf3ea7c3be3a84218a12c8a03) that is missing. While some objects are stored in individual files, others are packed: thousands of objects in a single file.

If you have object c168e82dd62c0cdbf3ea7c3be3a84218a12c8a03 you could extract it from your own repository, send it over, and insert it into the other repository. However, this is usually a lot harder than just re-cloning the good repository (provided it has everything—not every clone will be complete, e.g., it may be out of date, or it might be a --single-branch clone).

To extract the one object, first find its type:

git cat-file -t c168e82dd62c0cdbf3ea7c3be3a84218a12c8a03

Then extract its raw data:

git cat-file -p c168e82dd62c0cdbf3ea7c3be3a84218a12c8a03 > /tmp/obj.data

Copy the object data over and insert it into the repository:

scp /tmp/obj.data serverhost:/tmp/obj.data
ssh serverhost
cd ...
git hash-object -w -t $type /tmp/obj.data

where $type is the type from git cat-file -t on the machine with the good copy of the repository.

(Adding the missing object may fix everything, or may just expose more problems, which is another reason it's often preferable just to replace the bad repository entirely with another clone.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • Since I had an up to date repository on my local PC, I ended up cloning the repo with the --bare parameter and updating the server with those files, it worked like a charm. I'm still not sure why I had that corruption :( weird I'll keep an eye on the repository. – Leandros Sardinas Feb 12 '19 at 04:06
0

Since I had an up to date repository on my local PC, I ended up cloning the repository with the --bare parameter and updating the server with those files.

git clone --bare <path to clone from> <path to clone to>
Leandros Sardinas
  • 33
  • 2