Seseorang yang baik hati menulis sebuah skrip untuk melakukan ini secara otomatis (dan lebih teliti), tetapi proses pemulihan pada dasarnya adalah ini:
Periksa file yang melaporkan sampah, dengan hexdump.
$ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
Anda sedang mencari bagian dari file di mana ada sejumlah besar nol. Jika ada beberapa rentang seperti itu, saya sudah beruntung (N = 2) ketika mempertimbangkan hanya set nol pertama raksasa, bahkan ketika mereka memasukkan data kecil bukan nol. Ini adalah "sampah" yang dikeluhkan git.
...
0000500 0532 0302 0000 0000 0000 0000 0000 0000 # <-- Beginning here...
0000510 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000 # ... almost 3kb of zeros.
Dari sini Anda dapat menentukan ukuran sebenarnya dari objek. Di sini, itu akan menjadi 0x504 atau 1.284 byte.
Buat salinan cadangan objek. Jika Anda memilih set nol yang salah, Anda dapat mencoba lagi dengan set yang berbeda.
$ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
Pangkas file hingga panjang yang sesuai.
$ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
Objek yang korup sekarang harus diperbaiki. Dengan asumsi itu satu-satunya, mengkloning / mendorong / menarik repositori sekarang akan berfungsi seperti yang diharapkan.
Mengutip sumber saya, saya percaya saya telah mengalami masalah yang sama, tetapi dalam kasus saya menggunakan Ubuntu 10.4 (kernel 2.6.32-23-generic). Dalam hal ini, ini adalah bug sistem file yang belum dilacak. Ada masalah terbuka pada ecryptfs pada subjek ini dan juga utas usenet terkait . Sepanjang jalan menuju solusi, saya menemukan jawaban dan ringkasan berguna di StackOverflow. The artikel terkait sangat menarik, meskipun saya akhirnya pergi dengan cara yang berbeda.