Setiap kali saya menarik dari remote saya, saya mendapatkan kesalahan berikut tentang kompresi. Ketika saya menjalankan kompresi manual, saya mendapatkan yang sama:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Adakah yang tahu, apa yang harus dilakukan?

Dari file-cat saya mendapatkan ini:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

Dan dari git fsck saya mendapatkan ini (tidak tahu apakah ini benar-benar terkait):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Adakah yang bisa membantu saya menguraikan ini?

Sepertinya Anda memiliki objek pohon korup. Anda harus mendapatkan objek itu dari orang lain. Semoga mereka memiliki versi yang tidak rusak.

Anda benar-benar dapat merekonstruksi jika Anda tidak dapat menemukan versi yang valid dari orang lain dengan menebak file apa yang seharusnya ada. Anda mungkin ingin melihat apakah tanggal & waktu dari objek sesuai dengan itu. Itu bisa menjadi gumpalan terkait. Anda dapat menyimpulkan struktur objek pohon dari objek-objek itu.

Lihatlah Scott Chacon's Git Screencasts tentang git internal. Ini akan menunjukkan kepada Anda bagaimana git bekerja di bawah tenda dan bagaimana cara melakukan pekerjaan detektif ini jika Anda benar-benar terjebak dan tidak bisa mendapatkan objek itu dari orang lain.

Saya memiliki masalah yang sama (tidak tahu mengapa).

Perbaikan ini membutuhkan akses ke salinan repositori jarak jauh yang tidak rusak, dan akan membuat salinan lokal Anda tetap berfungsi.

Tetapi memiliki beberapa kelemahan:

• Anda akan kehilangan catatan komit apa pun yang tidak didorong, dan harus komitmen ulang mereka.
• Anda akan kehilangan simpanan.

Cara mengatasinya

Jalankan perintah ini dari direktori induk di atas repo Anda (ganti 'foo' dengan nama folder proyek Anda):

1. Buat cadangan direktori rusak:
   cp -R foo foo-backup
2. Buat tiruan baru dari repositori jauh ke direktori baru:
   git clone [email protected]:foo foo-newclone
3. Hapus subdirektori .git yang korup:
   rm -rf foo/.git
4. Pindahkan subdirektori .git yang baru diklon ke foo:
   mv foo-newclone/.git foo
5. Hapus sisa dari klon baru sementara:
   rm -rf foo-newclone

Di Windows Anda harus menggunakan:

• copy dari pada cp -R
• rmdir /S dari pada rm -rf
• move dari pada mv

Sekarang foo memiliki .gitsubdirektori aslinya kembali, tetapi semua perubahan lokal masih ada. git status, commit, pull, push, Dll bekerja lagi sebagaimana mestinya.

Taruhan terbaik Anda mungkin adalah dengan hanya mengkloning ulang dari repo jarak jauh (mis. Github atau lainnya). Sayangnya, Anda akan kehilangan komitmen yang tidak dicopot dan menyembunyikan perubahan, namun copy pekerjaan Anda tetap utuh.

Pertama buat salinan cadangan dari file lokal Anda. Kemudian lakukan ini dari akar pohon kerja Anda:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master  

Kemudian komit setiap file yang diubah seperlunya.

Bekerja pada VM, di notebook saya, baterai mati, mendapat kesalahan ini;

error: file objek .git / objek / ce / theRef kosong

Saya berhasil membuat repo berfungsi lagi dengan hanya 2 perintah dan tanpa kehilangan pekerjaan saya (file yang dimodifikasi / perubahan yang tidak dikomit)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

Setelah itu saya menjalankan git status, repo baik-baik saja dan ada perubahan saya (menunggu untuk dilakukan, lakukan sekarang ..).

git versi 1.9.1

Ingatlah untuk mencadangkan semua perubahan yang Anda ingat, kalau-kalau solusi ini tidak berfungsi dan diperlukan pendekatan yang lebih radikal.

Komputer saya macet ketika saya sedang menulis pesan komit. Setelah reboot, pohon yang berfungsi adalah seperti yang saya tinggalkan dan saya berhasil melakukan perubahan.

Namun, ketika saya mencoba lari, git statussaya dapat

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

Tidak seperti kebanyakan jawaban lain, saya tidak mencoba memulihkan data apa pun . Saya hanya perlu Git untuk berhenti mengeluh tentang file objek kosong.

Gambaran

"File objek" adalah representasi hash git dari file nyata yang Anda sayangi. Git berpikir itu seharusnya memiliki versi hashed yang some/file.whatevertersimpan .git/object/xx/12345, dan memperbaiki kesalahan ternyata sebagian besar masalah mencari tahu file mana "objek longgar" yang seharusnya diwakili.

Detail

Pilihan yang mungkin tampak

1. Hapus file kosong
2. Dapatkan file dalam kondisi yang dapat diterima oleh Git

Pendekatan 1: Hapus file objek

Hal pertama yang saya coba hanyalah memindahkan file objek

mv .git/objects/xx/12345 ..

Itu tidak berhasil - git mulai mengeluh tentang tautan yang rusak. Aktif ke Pendekatan 2.

Pendekatan 2: Perbaiki file

Linus Torvalds memiliki writeup yang bagus tentang bagaimana memulihkan file objek yang memecahkan masalah bagi saya. Langkah-langkah utama dirangkum di sini.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345  your_file.whatever

Ini memberitahu Anda apa file objek kosong seharusnya menjadi hash. Sekarang kamu bisa memperbaikinya.

$> git hash-object -w path/to/your_file.whatever

Setelah melakukan ini saya memeriksa .git/objects/xx/12345, itu tidak lagi kosong, dan git berhenti mengeluh.

Mencoba

git stash

Ini berhasil untuk saya. Ini menyembunyikan apa pun yang belum Anda lakukan dan yang mengatasi masalah.

Kumpulan sampah memperbaiki masalah saya:

git gc --aggressive --prune=now

Butuh beberapa saat untuk menyelesaikan, tetapi setiap objek longgar dan / atau indeks rusak diperbaiki.

cukup menjalankan git pruneperbaikan masalah ini untuk saya

Saya baru saja mengalami ini - mesin saya mogok saat menulis ke repo Git, dan menjadi rusak. Saya memperbaikinya sebagai berikut.

Saya mulai dengan melihat berapa banyak komit yang belum saya mendorong ke repo jarak jauh, dengan demikian:

gitk &

Jika Anda tidak menggunakan alat ini sangat berguna - tersedia di semua sistem operasi sejauh yang saya tahu. Ini menunjukkan bahwa remote saya kehilangan dua komit. Oleh karena itu saya mengklik label yang menunjukkan komit jarak jauh terbaru (biasanya ini akan /remotes/origin/master) untuk mendapatkan hash (hash panjangnya 40 karakter, tetapi untuk singkatnya saya menggunakan 10 di sini - ini biasanya tetap berfungsi).

Ini dia:

14c0fcc9b3

Saya kemudian klik pada komit berikut (yaitu yang pertama yang tidak dimiliki remote) dan mendapatkan hash di sana:

04d44c3298

Saya kemudian menggunakan keduanya untuk membuat patch untuk komit ini:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Saya kemudian melakukan hal yang sama dengan komit yang hilang lainnya, yaitu saya menggunakan hash dari commit sebelumnya dan hash dari commit itu sendiri:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Saya kemudian pindah ke direktori baru, mengkloning repo dari jarak jauh:

git clone [email protected]:username/repo.git

Saya kemudian memindahkan file tambalan ke folder baru, dan menerapkannya dan mengkomitnya dengan pesan komit yang tepat (ini dapat ditempel dari git logatau gitkjendela):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Ini memulihkan hal-hal untuk saya (dan perhatikan mungkin ada cara yang lebih cepat untuk melakukannya untuk sejumlah besar komitmen). Namun saya ingin melihat apakah pohon di repo yang rusak dapat diperbaiki, dan jawabannya adalah bisa. Dengan repo yang diperbaiki tersedia di atas, jalankan perintah ini di folder yang rusak:

git fsck 

Anda akan mendapatkan sesuatu seperti ini:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Untuk melakukan perbaikan, saya akan melakukan ini di folder yang rusak:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

yaitu menghapus file yang rusak dan menggantinya dengan yang baik. Anda mungkin harus melakukan ini beberapa kali. Akhirnya akan ada titik di mana Anda dapat menjalankan fscktanpa kesalahan. Anda mungkin akan memiliki garis "menggantung komit" dan "menggantung gumpalan" dalam laporan, ini adalah konsekuensi dari rebases Anda dan mengubah dalam folder ini, dan itu OK. Pengumpul sampah akan menghapusnya pada waktunya.

Jadi (setidaknya dalam kasus saya) pohon yang rusak tidak berarti komitmen yang tidak dicuri akan hilang.

Saya mendapatkan kesalahan objek longgar korup juga.

./objects/x/x

Saya berhasil memperbaikinya dengan masuk ke direktori objek yang rusak. Saya melihat bahwa pengguna yang ditugaskan ke objek itu bukan pengguna git saya. Saya tidak tahu bagaimana itu terjadi, tetapi saya menjalankan chown git:gitfile itu dan kemudian bekerja lagi.

Ini mungkin merupakan perbaikan potensial untuk masalah beberapa orang tetapi tidak perlu semuanya.

Saya mendapatkan kesalahan ini setelah mesin (windows) saya memutuskan untuk reboot sendiri. Untungnya repo jarak jauh saya sudah mutakhir, jadi saya baru saja melakukan kloning git ..

Runnning git stash; git stash popmemperbaiki masalah saya

Saya mengikuti banyak langkah lain di sini; Deskripsi Linus tentang cara melihat pohon git / objek dan menemukan apa yang hilang sangat membantu. git-git memulihkan gumpalan rusak

Tetapi pada akhirnya, bagi saya, saya memiliki objek pohon longgar / rusak yang disebabkan oleh kegagalan sebagian disk, dan objek pohon tidak begitu mudah dipulihkan / tidak tercakup oleh dokumen itu.

Pada akhirnya, saya memindahkan yang bertentangan objects/<ha>/<hash>keluar dari jalan, dan digunakan git unpack-objectsdengan file paket dari klon yang cukup mutakhir. Itu mampu mengembalikan objek pohon yang hilang.

Masih meninggalkan saya dengan banyak gumpalan menjuntai, yang dapat menjadi efek samping dari membongkar barang-barang yang sebelumnya diarsipkan, dan dibahas dalam pertanyaan lain di sini

Sebagai jawaban dari @ user1055643 hilang langkah terakhir:

$ rm -fr .git
$ git init
$ git remote add origin your-git-remote-url
$ git fetch
$ git reset --hard origin/master
$ git branch --set-upstream-to=origin/master master  

Kami baru saja membawa kopernya di sini. Terjadi bahwa masalahnya adalah kepemilikan file yang rusak adalah root, bukan pengguna normal kami. Ini disebabkan oleh komit yang dilakukan pada server setelah seseorang melakukan "sudo su -".

Pertama, kenali file Anda yang rusak dengan:

$> git fsck --full

Anda harus menerima jawaban seperti ini:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Buka folder tempat file korup berada dan lakukan:

$> ls -la

Periksa kepemilikan file yang rusak. Jika itu berbeda, kembali saja ke root repo Anda dan lakukan:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Semoga ini bisa membantu!

Bagi saya ini terjadi karena kegagalan daya saat melakukan a git push.

Pesannya terlihat seperti ini:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Saya mencoba hal-hal seperti git fscktetapi itu tidak membantu. Karena crash terjadi selama git push, itu jelas terjadi selama penulisan ulang di sisi klien yang terjadi setelah server diperbarui. Saya melihat sekeliling dan menemukan bahwa c2388dalam kasus saya adalah objek komit, karena dirujuk oleh entri di .git/refs. Jadi saya tahu bahwa saya akan dapat menemukan c2388ketika saya melihat sejarah (melalui antarmuka web atau klon kedua).

Pada klon kedua saya melakukan git log -n 2 c2388untuk mengidentifikasi pendahulunya c2388. Kemudian saya secara manual dimodifikasi .git/refs/heads/masterdan .git/refs/remotes/origin/mastermenjadi pendahulu c2388alih-alih c2388. Maka saya bisa melakukan git fetch. The git fetchgagal beberapa kali konflik pada objek kosong. Saya menghapus masing-masing benda kosong ini sampai git fetchberhasil. Itu telah menyembuhkan repositori.

Saya memecahkan masalah ini: Saya memutuskan untuk hanya menyalin file objek yang tidak rusak dari klon cadangan ke repositori asli saya. Ini berhasil juga. (Ngomong-ngomong: Jika Anda tidak dapat menemukan objek di .git / objek / dengan namanya, itu mungkin telah [dikemas] [paket] untuk menghemat ruang.)

Saya memiliki masalah yang sama pada repo git saya yang sederhana. Setelah banyak pemecahan masalah, saya menemukan salah satu rekan kerja saya telah membuat komit di mana beberapa file di .git / objek memiliki izin 440 (r - r -----) daripada 444 (r - r - r -). Setelah meminta rekan kerja untuk mengubah izin dengan "chmod 444 -R objek" di dalam bare git repo, masalahnya diperbaiki.

Saya hanya punya masalah seperti ini. Masalah khusus saya disebabkan oleh sistem crash yang merusak komit terbaru (dan karenanya juga cabang master). Saya tidak mendorong, dan ingin membuat kembali komitmen itu. Dalam kasus khusus saya, saya bisa menghadapinya seperti ini:

1. Buat cadangan .git/:rsync -a .git/ git-bak/
2. Periksa .git/logs/HEAD, dan temukan baris terakhir dengan ID komit yang valid. Bagi saya, ini adalah komit terbaru kedua. Ini bagus, karena saya masih memiliki versi direktori file yang berfungsi, dan setiap versi yang saya inginkan.
3. Buat cabang di komit itu: git branch temp <commit-id>
4. lakukan kembali komit yang rusak dengan file di direktori kerja.
5. git reset master temp untuk memindahkan cabang master ke komit baru yang Anda buat pada langkah 2.
6. git checkout masterdan periksa apakah itu benar git log.
7. git branch -d temp.
8. git fsck --full, dan sekarang seharusnya aman untuk menghapus objek yang rusak yang ditemukan fsck.
9. Jika semuanya terlihat bagus, cobalah mendorong. Jika itu berhasil,

Itu berhasil untuk saya. Saya menduga ini adalah skenario yang cukup umum, karena komit terbaru adalah yang paling mungkin rusak, tetapi jika Anda kehilangan satu lagi, Anda mungkin masih dapat menggunakan metode seperti ini, dengan penggunaan hati-hati git cherrypick, dan reflog di .git/logs/HEAD.

Ketika saya memiliki masalah ini, saya mendukung perubahan terbaru saya (karena saya tahu apa yang telah saya ubah) kemudian menghapus file yang dikeluhkannya di .git / lokasi. Lalu aku melakukan git pull. Berhati-hatilah, ini mungkin tidak berhasil untuk Anda.

Saya mengalami ini setelah sistem saya crash. Apa yang saya lakukan adalah ini:

(Harap perhatikan bahwa komit korup Anda hilang, tetapi perubahan tetap dipertahankan. Anda mungkin harus membuat ulang komit tersebut di akhir prosedur ini)

• Cadangkan kode Anda.
• Buka direktori kerja Anda dan hapus .gitfolder.
• Sekarang klon remote di lokasi lain dan salin .gitfolder di dalamnya.
• Rekatkan di direktori kerja Anda.
• Berkomitmenlah seperti yang Anda inginkan.

Hapus saja folder .git dan tambahkan lagi. Solusi sederhana ini berhasil untuk saya.