Uzaktan kumandamdan ne zaman çeksem sıkıştırmayla ilgili şu hatayı alıyorum. Manuel sıkıştırmayı çalıştırdığımda, aynı şeyi alıyorum:

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

Kimse biliyor, bu konuda ne yapmalı?

Kedi dosyasından bunu alıyorum:

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

Ve git fsck bunu (gerçekten ilgili olup olmadığını bilmiyorum) olsun:

$ 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

Birisi bunu çözmeme yardım edebilir mi?

Görünüşe göre bozuk bir ağaç nesneniz var. Bu nesneyi bir başkasından almanız gerekecek. Umarım bozulmamış bir versiyona sahip olurlar.

Orada hangi dosyaların olması gerektiğini tahmin ederek başka birinden geçerli bir sürüm bulamazsanız, yeniden yapılandırabilirsiniz. Nesnelerin tarih ve saatlerinin kendisiyle eşleşip eşleşmediğini görmek isteyebilirsiniz. Bunlar ilgili lekeler olabilir. Ağaç nesnesinin yapısını bu nesnelerden çıkarabilirsiniz.

Git dahili ile ilgili Scott Chacon'un Git Screencasts'larına bir göz atın . Bu, git'in kaputun altında nasıl çalıştığını ve gerçekten sıkışıp kalırsanız ve o nesneyi başka birinden alamazsanız, bu dedektif çalışmasını nasıl yapacağınızı gösterecektir.

Aynı sorunu yaşadım (neden bilmiyorum).

Bu düzeltme, deponun kesintisiz bir uzak kopyasına erişim gerektirir ve yerel olarak çalışan kopyanızı olduğu gibi bırakır.

Ancak bazı dezavantajları var:

• Zorlanmayan taahhütlerin kaydını kaybedeceksiniz ve onları tavsiye etmek zorunda kalacaksınız.
• Zararınızı kaybedeceksiniz.

Çözüm

Bu komutları deponuzun üst dizininden yürütün ('foo' yerine proje klasörünüzün adını yazın):

1. Bozuk dizinin yedeğini oluşturun:
   cp -R foo foo-backup
2. Yeni bir dizine uzak deponun yeni bir kopyasını oluşturun:
   git clone git@www.mydomain.de:foo foo-newclone
3. Bozuk .git alt dizinini silin:
   rm -rf foo/.git
4. Yeni klonlanan .git alt dizinini foo'ya taşıyın:
   mv foo-newclone/.git foo
5. Geçici yeni klonun kalanını silin:
   rm -rf foo-newclone

Windows'ta şunları kullanmanız gerekir:

• copy onun yerine cp -R
• rmdir /S onun yerine rm -rf
• move onun yerine mv

Şimdi foo'nun orijinal .gitalt dizini vardır , ancak tüm yerel değişiklikler hala oradadır. git status, commit, pull, push, Olması gerektiği gibi tekrar vb işler.

En iyi seçeneğiniz muhtemelen uzak repodan (yani Github veya diğer) yeniden klonlamaktır. Maalesef itilmemiş taahhütleri ve saklanmış değişiklikleri kaybedeceksiniz, ancak çalışma kopyanız bozulmadan kalmalıdır.

Önce yerel dosyalarınızın yedek bir kopyasını oluşturun. Sonra bunu çalışma ağacınızın kökünden yapın:

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  

Ardından, değiştirilen dosyaları gerektiği gibi uygulayın.

Dizüstü bilgisayarımda bir VM üzerinde çalışan pil öldü, bu hatayı aldı;

hata: nesne dosyası .git / objects / ce / theRef boş hata: nesne dosyası .git / objects / ce / theRef boş ölümcül: gevşek nesne theRef (.git / objects / ce / theRef içinde saklanır) bozuk

Repoyu sadece 2 komutla ve işimi kaybetmeden tekrar çalıştırmayı başardım (değiştirilmiş dosyalar / taahhüt edilmemiş değişiklikler)

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

Ondan sonra koştum git status, repo iyiydi ve değişikliklerim vardı (taahhüt edilmeyi bekliyor, şimdi yap ..).

git sürüm 1.9.1

Bu çözüm işe yaramazsa ve daha radikal bir yaklaşıma ihtiyaç duyulursa hatırladığınız tüm değişiklikleri yedeklemeyi unutmayın.

Bir taahhüt mesajı yazarken bilgisayarım çöktü. Yeniden başlattıktan sonra, çalışma ağacı bıraktığım gibiydi ve değişiklikleri başarıyla gerçekleştirebildim.

Denedim Ancak, çalıştırmak için git statusbende

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

Diğer cevapların çoğundan farklı olarak, herhangi bir veriyi kurtarmaya çalışmıyordum . Git için boş nesne dosyasıyla ilgili şikayeti durdurmak için ihtiyacım vardı.

genel bakış

"Nesne dosyası" git'in önemsediğiniz gerçek bir dosyanın karma temsilidir. Git, some/file.whateversaklanmış karma bir sürümüne sahip olması gerektiğini düşünüyor .git/object/xx/12345ve hatayı düzeltmenin, çoğunlukla "gevşek nesnenin" temsil etmesi gereken dosyayı bulma sorunu olduğu ortaya çıktı.

ayrıntılar

Olası seçenekler

1. Boş dosyayı sil
2. Dosyayı Git tarafından kabul edilebilir bir duruma getirin

Yaklaşım 1: Nesne dosyasını kaldırın

Denediğim ilk şey sadece nesne dosyasını taşımaktı

mv .git/objects/xx/12345 ..

Bu işe yaramadı - git kopuk bir bağlantıdan şikayet etmeye başladı. Yaklaşıma Açık 2.

Yaklaşım 2: Dosyayı düzeltin

Linus Torvalds, benim için problemi çözen bir nesne dosyasının nasıl kurtarılacağına dair harika bir yazıya sahip . Anahtar adımlar burada özetlenmiştir.

$> # 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

Bu, boş nesnenin karma olması gereken dosyayı belirtir. Şimdi onarabilirsiniz.

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

Bunu yaptıktan sonra kontrol ettim .git/objects/xx/12345, artık boş değildi ve git şikayet etmeyi bıraktı.

Deneyin

git stash

Bu benim için çalıştı. Taahhüt etmediğin ve sorunun üstesinden gelen her şeyi saklıyor.

Bir çöp toplama sorunumu düzeltti:

git gc --aggressive --prune=now

Tamamlanması biraz zaman alır, ancak her gevşek nesne ve / veya bozuk dizin düzeltildi.

sadece çalışan git prunebenim için bu sorunu giderilmiştir

Bunu yeni yaşadım - Git deposuna yazarken makinem çöktü ve bozuldu. Aşağıdaki gibi sabitledim.

Uzak repoya kaçmadığım için ne kadar taahhütte bulunduğuma baktım, böylece:

gitk &

Bu aracı kullanmazsanız çok kullanışlıdır - bildiğim kadarıyla tüm işletim sistemlerinde kullanılabilir. Bu, uzaktan kumandamın iki taahhüt eksik olduğunu gösterdi. Bu nedenle en son uzaktan taahhüdü gösteren etikete tıkladım (genellikle bu/remotes/origin/master hash almak için ) (karma 40 karakter uzunluğunda, ancak kısalık için burada 10 kullanıyorum - bu genellikle yine de işe yarıyor).

İşte burada:

14c0fcc9b3

Daha sonra aşağıdaki taahhüdü (yani, uzaktan kumandanın sahip olmadığı ilk) tıklayın ve hash'ı oraya getirin:

04d44c3298

Daha sonra bu taahhüt için bir yama yapmak için her ikisini de kullanın:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Daha sonra diğer eksik işlemlerle benzer şekilde yaptım, yani daha önce işlemin karmasını ve işlemin kendisinin karmasını kullandım:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Sonra yeni bir dizine taşındım, uzaktan kumandadan repo kopyaladım:

git clone git@github.com:username/repo.git

Daha sonra yama dosyalarını yeni klasöre taşıdım ve uyguladım ve kesin taahhüt mesajlarıyla taahhüt ettim (bunlar yapıştırılabilir git logveya gitkpencereden):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Bu benim için işleri geri getirdi (ve muhtemelen çok sayıda taahhütte yapmanın daha hızlı bir yolu olduğunu unutmayın). Ancak ben bozuk repo ağacın tamir edilip edilemeyeceğini görmek istedim ve cevap olabilir. Onarılmış bir repo yukarıdaki gibi mevcutsa, bu komutu bozuk klasörde çalıştırın:

git fsck 

Bunun gibi bir şey alacaksınız:

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

Onarım yapmak için, ben kırık klasörde bunu yaparım:

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

yani bozuk dosyayı kaldırın ve iyi bir dosyayla değiştirin. Bunu birkaç kez yapmak zorunda kalabilirsiniz. Sonunda koşabileceğiniz bir nokta olacakfsck hatasız . Muhtemelen raporda "sarkan taahhüt" ve "sarkan damla" satırlarına sahip olacaksınız. Bunlar, bu klasördeki temel ve değişikliklerin bir sonucudur ve sorun değildir. Çöp toplayıcı onları zamanında çıkarır.

Böylece (en azından benim durumumda) bozuk bir ağaç, baskısız taahhütlerin kaybolduğu anlamına gelmez.

Ben de bozuk bir gevşek nesne hatası alıyordum.

./objects/x/x

Başarıyla bozuk nesnenin dizinine giderek düzeltti. Bu nesneye atanan kullanıcıların benim git kullanıcım olmadığını gördüm. Nasıl olduğunu bilmiyorum, amachown git:git o dosya üzerinde ve sonra tekrar çalıştı.

Bu, bazı insanların sorunları için potansiyel bir düzeltme olabilir, ancak hepsi gerekli değildir.

(Windows) makinem kendini yeniden başlatmaya karar verdikten sonra bu hatayı aldım. Neyse ki benim uzaktan repo güncel oldu, bu yüzden sadece taze git-klon yaptım ..

Runnning git stash; git stash popsorunumu düzeltti

Buradaki diğer adımların çoğunu izledim; Linus'un git ağacına / nesnelerine nasıl bakılacağını ve eksik olanı nasıl bulacağına dair açıklaması özellikle yardımcı oldu. git-git bozuk damla kurtarmak

Ama sonunda, benim için, kısmi bir disk arızasından kaynaklanan gevşek / bozuk ağaç nesnelerim vardı ve ağaç nesneleri o kadar kolay kurtarılamıyor / bu dokümanın kapsamına girmiyor.

Sonunda, çatışmayı objects/<ha>/<hash>ortadan git unpack-objectskaldırdım ve makul bir güncel klondan bir paket dosyasıyla kullandım . Kayıp ağaç nesnelerini geri yükleyebildi.

Hala beni daha önce arşivlenmiş şeyleri açmanın bir yan etkisi olabilecek ve burada başka sorularda ele alınan bir sürü sarkan damla bıraktı.

@ User1055643 yanıtında son adım eksik:

$ 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  

Burada sadece durum vardı. Sorun, normal kullanıcı yerine bozuk dosyanın sahipliğinin kök olmasıydı. Bu, birisi "sudo su -" yaptıktan sonra sunucuda yapılan bir taahhütten kaynaklandı.

İlk olarak, bozuk dosyanızı aşağıdakilerle tanımlayın:

$> git fsck --full

Bunun gibi bir cevap almalısınız:

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

Bozuk dosyanın bulunduğu klasöre gidin ve şunları yapın:

$> ls -la

Bozuk dosyanın sahipliğini kontrol edin. Bu farklıysa, repo kökünüze geri dönün ve şunları yapın:

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

Umarım yardımcı olur!

Benim için bu bir güç kesintisi nedeniyle oldu git push.

Mesajlar şöyle görünüyordu:

$ 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

Gibi şeyler denedim git fsckama bu yardımcı olmadı. Kilitlenme bir git pushsırasında meydana geldiğinden, sunucu güncelleştirildikten sonra gerçekleşen istemci tarafında yeniden yazma sırasında açıkça görülmüştür. Etrafıma baktım ve c2388benim durumumda bir taahhüt nesnesi olduğunu anladım , çünkü içeriğe girdiler .git/refs. Bu yüzden c2388tarihe baktığımda bulabileceğimi biliyordum (bir web arayüzü veya ikinci klon aracılığıyla).

İkinci klonda git log -n 2 c2388selefini tanımlamak için bir yaptım c2388. Sonra el ile değiştirdim .git/refs/heads/masterve yerine .git/refs/remotes/origin/masterselefi olmak . Sonra yapabilirim . Boş nesneler üzerinde çatışmalar için bir kaç kez başarısız oldu. Başarılı olana kadar bu boş nesnelerin her birini kaldırdım . Depoyu iyileştirdi.c2388c2388git fetchgit fetchgit fetch

Bu şekilde çözdüm: Bozuk olmayan nesne dosyasını yedeklemenin klonundan orijinal havuzuma kopyalamaya karar verdim. Bu da işe yaradı. (Bu arada: Nesneyi .git / objects / adında bulamazsanız, alandan tasarruf etmek için muhtemelen [paketlenmiş] [paket] olmuştur.)

Aynı sorun benim çıplak uzak git repo vardı. Çok fazla sorun giderme işleminden sonra, iş arkadaşlarımdan birinin .git / nesnelerdeki bazı dosyaların 444 (r - r - r) yerine 440 (r - r -----) izinlerine sahip olduğu bir taahhütte bulunduğunu anladım. -). İş arkadaşınızdan çıplak git repo içindeki "chmod 444 -R nesneleri" ile izinleri değiştirmesini istedikten sonra sorun giderildi.

Sadece böyle bir sorun yaşadım. Benim özel sorunum, en son taahhüdü (ve dolayısıyla ana dalı) bozan bir sistem çökmesinden kaynaklandı. Ben itmedim ve bu taahhüdü yeniden yapmak istedim. Benim özel durumumda, bununla başa çıkabildim:

1. Şunun bir yedeğini alın .git/:rsync -a .git/ git-bak/
2. Kontrol .git/logs/HEADGeçerli bir taahhüt kimliğine sahip son satırı ve bulun. Benim için bu en son ikinci taahhütti. Bu iyiydi, çünkü hala dosyanın çalışma dizini sürümlerine sahiptim ve böylece istediğim her sürüm vardı.
3. Bu taahhütte bir şube yapın: git branch temp <commit-id>
4. çalışma dizinindeki dosyalar ile kırık işlemi yeniden yapın.
5. git reset master temp ana dalı 2. adımda yaptığınız yeni taahhüde taşımak için.
6. git checkout masterve doğru göründüğünü kontrol edin git log.
7. git branch -d temp.
8. git fsck --fullve artık fsck'in bulduğu bozuk nesneleri silmek güvenli olmalıdır.
9. Her şey iyi görünüyorsa, itmeyi deneyin. Bu işe yararsa,

Bu benim için çalıştı. Bunun son derece yaygın bir senaryo olduğundan şüpheliyim, çünkü en son taahhüt bozulma olasılığı en yüksek olanıdır, ancak bir tane daha geri kaybederseniz, yine de dikkatli bir şekilde git cherrypickve reflog ile böyle bir yöntem kullanabilirsiniz. içinde .git/logs/HEAD.

Ne zaman bu sorunu vardı (ben ne değişti biliyordu) son değişiklikleri yedekledi sonra .git / location hakkında şikayet olduğunu bu dosyayı sildi. Sonra bir git çekme yaptım. Yine de, bu sizin için işe yaramayabilir.

Sistemim çöktüğünde bununla karşılaştım. Ne yaptım bu:

(Lütfen yolsuz taahhütlerinizin kaybolduğunu, ancak değişikliklerin korunduğunu unutmayın. Bu prosedürün sonunda bu taahhütleri yeniden oluşturmanız gerekebilir)

• Kodunuzu yedekleyin.
• Çalışma dizininize gidin ve .gitklasörü silin .
• Şimdi uzaktan kumandayı başka bir yerde klonlayın ve içindeki .gitklasörü kopyalayın .
• Çalışma dizininize yapıştırın.
• İstediğin gibi taahhüt et.

Sadece .git klasörünü kaldırın ve tekrar ekleyin. Bu basit çözüm benim için çalıştı.