GIT Hatası Nasıl Düzeltilir: Nesne dosyası boş mu?


442

Değişiklikleri yapmaya çalıştığımda şu hatayı alıyorum:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Bu hatayı nasıl çözeceğiniz hakkında bir fikriniz var mı?

DÜZENLE

Denedim denedim git fsck:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

Bir git addoperasyonu zorla öldürdün mü ? Sabit diskiniz dolu mu?
cdhowie

Hayır, sabit diskim dolu değil, git ekleme işlemini zorla öldürdüğümü hatırlamıyorum, ya yapsaydım? Bunu Nasıl Çözebilirim ?
simo

hayır, hata hala orada ...
simo

2
Bu havuz uzak bir depoda bulunuyorsa, uzak deponuzda varsa o dosyayı oradan yerel olanınıza kopyalamayı deneyebilirsiniz.
Attila Szeremi

2
.Git dizinindeki izinlerim bir şekilde berbat olduğunda ve okuma erişimim olmadığında bu hatayı aldım. Bu nedenle dosyaların boş olmadığı, ancak yazılamadığı durumlarda olabilir. İzinleri düzeltmek ve çalıştırmak git fsckbunu halletti.
Jake Anderson

Yanıtlar:


900

Benzer bir sorun yaşadım. Git işlemi sırasında dizüstü bilgisayarımın pili bitti. Boo.

Yedeklerim yoktu. (NB Ubuntu One git için bir yedekleme çözümü değildir; akıllıca deponuzun bozuk olanınızla üzerine yazılmasına yardımcı olacaktır.)

Git sihirbazlarına, bu düzeltmenin kötü bir yoluysa, lütfen bir yorum bırakın. Ancak, benim için çalıştı ... en azından geçici olarak.

Adım 1: .git'in bir yedeğini alın (aslında bunu bir şeyi değiştiren her adım arasında yapıyorum, ancak yeni bir kopya adı ile, örneğin .git-old-1, .git-old-2, vb.) :

cp -a .git .git-old

2. Adım: Çalıştırın git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Adım 3: Boş dosyayı kaldırın. Ne halt olduğunu düşündüm; zaten boş.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

3. Adım: git fsckTekrar çalıştırın . Boş dosyaları silmeye devam edin. Ayrıca edebilirsiniz cdiçine .gitdizin ve çalıştırmak find . -type f -empty -delete -printtüm boş dosyaları kaldırmak için. Sonunda git bana aslında nesne dizinleri ile bir şeyler yaptığını söylemeye başladı:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Adım 4: Tüm boş dosyaları sildikten sonra, sonunda git fsckgerçekten çalışmaya başladım :

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

5. Adım: Deneyin git reflog. Başarısız çünkü KAFA kırıldı.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

6. Adım: Google. Bunu bul . Reflog'un son iki satırını manuel olarak alın:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400  commit: fixed up to page 28

Adım 7: Adım 6'dan itibaren HEAD'in şu anda son taahhüdü işaret ettiğini öğrendiğimizi unutmayın. Öyleyse sadece ebeveyn taahhüdüne bakmaya çalışalım:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

İşe yaradı!

Adım 8: Şimdi HEAD'ı 9f0abf890b113a287e10d56b66dbab66adc1662d'ye yönlendirmemiz gerekiyor.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Hangi şikayet etmedi.

Adım 9: FSck'in ne dediğine bakın:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Adım 10: Önbellek ağacındaki geçersiz sha1 işaretçisi, (şimdi eskimiş) bir dizin dosyasından ( kaynak ) gelmiş gibi görünüyordu . Ben de öldürdüm ve repoyu sıfırladım.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Adım 11: Fsck'e tekrar bakmak ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

Sarkan lekeler hatalar değildir . Master.u1conflict ile ilgilenmiyorum ve şimdi çalıştığı için artık ona dokunmak istemiyorum!

Adım 12: Yerel düzenlemelerime yetişmek:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Umarım bu gelecekte insanlar için yararlı olabilir. Çalıştığına sevindim.


86
Tüm adımlar ve her şeyle birlikte mükemmel cevap. Sanırım beni her birini google'dan kurtardın!
Zlatko

24
Bir cazibe gibi çalıştı! Keşke bu defalarca
oy verebilsem

1
Hmm, dizüstü bilgisayarım bir git işlemi sırasında öldü (SparkleShare notlarımı öldüğü gibi işlemeye çalışıyordu) ve bundan sonra repo bu şekilde bozuldu. 6'ya kadar adımlarınızı takip ettim ama son birkaç taahhüdün aslında sildiğim boş nesne dosyalarının bir parçası olduğu anlaşılıyor mu? Aslında son 3 taahhüt temelde tamamen kırıldı bu yüzden yapabileceğim bir şey yoktu sanırım. Neyse ki, aslında SparkleShare'den bireysel taahhütlere ihtiyacım yok ve sadece kirli dosyayı bir makineden diğerine kopyalayabilir ve birleştirebilirim.
İbrahim

14
Müthiş, müthiş bir cevap. Özellikle her adımın arkasındaki akıl yürütmenizi eklediğiniz için teşekkür ederiz. Reporumu kurtardın! (Eh, fsck'ten hala 'refs / heads / master için kötü bir ref' hatası var, ancak bu nispeten hafif.)
Jon Carter

3
Teşekkürler, pastırmamı da önemli bir taahhütte saklarken, bazı git işlevselliği hakkında çok şey öğrendim! Tesadüfen, dizüstü bilgisayardaki düşük pil nedeniyle de oldu.
HarbyUK

196

Git nesne dosyaları bozuldu (diğer cevaplarda da belirtildiği gibi). Bu, makine çökmeleri vb. Sırasında olabilir.

Aynı şeye sahiptim. Burada diğer en iyi yanıtları okuduktan sonra aşağıdaki komutlarla kırık git deposunu düzeltmenin en hızlı yolunu buldum ( .gitklasörü içeren git çalışma dizininde yürütün ):

(Önce git depo klasörünüzü yedeklediğinizden emin olun!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

Bu, önce deponun bir bütün olarak bozulmasına neden olan boş nesne dosyalarını kaldıracak ve daha sonra uzaktaki depodan eksik nesneleri (ve en son değişiklikleri) getirecek ve daha sonra tam bir nesne deposu denetimi yapacak . Bu noktada, herhangi bir hata olmadan başarılı olmalıdır (yine de bazı uyarılar olabilir!)

PS. Bu yanıt, git deponuzun bir yerde (örneğin GitHub'da) uzak bir kopyasına sahip olduğunuzu ve bozuk deponun, hala takılmakta olan uzak depoya bağlı yerel havuz olduğunu göstermektedir. Durum böyle değilse, önerdiğim şekilde düzeltmeye çalışmayın.


Bunun için teşekkürler, uzak şubelerime oldukça dindar bir şekilde itiyorum ve çözümünüz benim için çalıştı. İlk önce @ mCorr'un denedim ama yeni dosyaları taahhüt ettikten sonra repo bozulmaya geri döndü. Bu yaklaşım bunu çözdü
mr_than

çoğu uzaktan kumanda var gibi. Bu çözüm gerçekten temiz ve yeterli.
jackOfTüm

7
Ben git repo ile çalışıyordu bir VM kapattıktan sonra bu sorun vardı. Bu çözüm mükemmel çalıştı.
Giscard Biamby

Teşekkürler Martin, mükemmel ve kompakt bir çözüm. Naif kullanıcıların sadece yerel bir kurulumda aynı şeyi denemesini önlemek için bu PS'yi ilk önce, kalın olarak uyarı ile koyabilirim. Giscard gibi, bu da bir VM kapatıldığında ortaya çıkıyor ... bunu her seferinde yapmaktan daha kalıcı bir çözüm bulursam güncellenir.
thclark

2
Bir VM ezmesi bunu yerel git
repo'ma da yaptı

35

Bu hata, taahhüdümü zorladığımda başıma geliyor ve bilgisayarım askıda. Ben böyle düzeltirim.


Düzeltme adımları

git status

boş / bozuk nesne dosyasını göster

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

onu kaldır

git status

Bende fatal: bad object HEADmesajı

rm .git/index

indexSıfırlama için kaldırdım

git reset

fatal: 'HEAD' nesnesi ayrıştırılamadı.

git status
git pull

sadece ne olduğunu kontrol etmek için

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

son 2 satırımı tail -n 2göstermek için günlük dalının son 2 satırını yazdırırcommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Sonuncuyu seçiyorum commit hash

git status

Bütün olarak dosyamı gösterir deletedı kaldırıldı çünkü .git/indexdosyayı

git reset

sıfırlamaya devam et

git status

düzeltmemi doğrula


Not: Adımlar bu soruya geldiğimde ve cevapları referans olarak kullandığımda başlar.


34

Bu git fsck tespit çeşitli boş dosyaları kaldırarak ve sonra basit bir git çekme çalışan çözüldü.

Dosya sistemlerinin bile fs aklını korumak için günlük kaydı ve diğer "işlemsel" teknikleri uyguladığı hayal kırıklığı yaratıyor, git bir elektrik kesintisi veya cihazdaki alan nedeniyle bozuk bir duruma gelebilir (ve kendi kendine kurtulamayabilir).


3
Yukarıdaki cevabın teknik olarak daha iyi olduğuna eminim, ancak 6. adımda çalışmayı durdurdu ve teknik olarak başımın çok üzerindeydi. Uygun yaklaşım git pull
mblackwell8

2
Nathan'ın cevabındaki talimatların 1-11 adımlarını (harika çalıştı!) Yaptıktan sonra, refs / origin / master ve refs / origin / head'in tanımlanmadığını (veya bunun gibi bir şey) ) o. git bunu düzeltti. Bence her iki çözüm de birlikte çalışıyor.
bchurchill

2
Kullanılan dosya sistemlerinin normalde yalnızca meta verileri günlüğe kaydettiğinin farkındayım. Veriler için günlük kaydını da açabilirsiniz, ancak genel gider nedeniyle varsayılan olmadığını tahmin ediyorum (?) Bu yüzden muhtemelen dosyalar boştu .... ve dosya sistemleri genellikle dosya başına işlemleri gözlemlerken git'te birden fazla dosya değiştiriliyor işlem başına, bu nedenle fs dosya başına tutarlılığı korur, git gitmezse, o zaman git tutarsız durumlara yol
açacaktır

Bu cevap benim için çalıştı, diğerleri karmaşık bir yol.
ldog

1
Kabul edilen cevaptan çok daha hızlı bir çözüm. Bu kadar ilerleyen herkese, aceleniz varsa bu cevabı takip edin.
Sri Harsha Kappala

9

Ben sadece aynı sorunu vardı: uzak depoyu çektikten sonra, bir git durumu yaptığımda aldım: "hata: nesne dosyası (...) boş" "ölümcül: gevşek nesne (...) bozuk"

Bunu çözmenin yolu şuydu:

  1. git stash
  2. git dosyasını yanlışlıkla kaldırma (gerekli olduğundan emin değilim)
  3. git stash temizle

Ne olduğunu tam olarak bilmiyorum, ama bu talimatlar her şeyi temiz yapıyor gibiydi.


2
Her zaman daha basit cevapları severim :) Adım 2 için burada @Nathan VanHoudnos'un cevabında verilen komutu kullandım:cd .git/ && find . -type f -empty -delete
mopo922

8

Sanal makinemi düzenli olarak yeniden başlatmam gerektiğinden, bu sorun bana bir şekilde çok sık oluyor. Birkaç kez sonra, @ Nathan-Vanhoudnos tarafından açıklanan işlemi her gerçekleştiğinde tekrarlayamayacağımı fark ettim, her zaman işe yarıyor. Sonra aşağıdaki daha hızlı çözümü buldum.

Aşama 1

Tüm deponuzu başka bir klasöre taşıyın.

mv current_repo temp_repo

Adım 2

Repoyu tekrar başlangıçtan klonlayın.

git clone source_to_current_repo.git

Aşama 3

Yeni repo altındaki .git klasörü dışındaki her şeyi kaldırın .

4. Adım

Taşı Everything gelen temp_repo yeni repo hariç .git klasöre.

Adım 5

Kaldır Temp_repo'yu işimiz bitti.

Birkaç kez sonra, bu prosedürleri çok hızlı bir şekilde yapabileceğinizden eminim.


2
Ya da mevcut git clone source_to_current_repo.git clean_repodeponuzu hareket ettirmeyin, 1) yeni bir klon oluşturun , 2) eski .git klasörünü yedekleyin, 3) temiz .git klasörünün üzerine kopyalayın.
moi

Haklısın. Şimdi zaten yaptım. Cevabı daha sonra düzenleyecek.
haoqiang

@haoqiang: "Sanal makinemi düzenli olarak yeniden başlatmam gerektiğinden, bu şekilde bir şekilde başıma çok sık geliyor." Biz de aynı şeyi yaşıyoruz. Temel neden - sorunun daha az gerçekleşmesini sağlayan VM ayarları konusunda ilerleme kaydettiniz mi?
hansfn

6
  1. mv yedekleme yapmak için klasör uygulamanız, yani mv app_folder app_folder_bk (bir git stash gibi )
  2. git clone Instagram Hesabındaki Resim ve Videoları your_repository
  3. En sonunda,. Bir birleştirme aracı açın (meld diff görüntüleyici linux veya Winmerge Windows kullanıyorum) ve değişiklikleri sağdan ( app_folder_bk ) sola (yeni app_folder ) kopyalayın ( git stash uygulaması gibi ).

Bu kadar. Belki de en iyi yol bu değildir, ama bence çok pratik.


1
Tüm yerel değişiklikler bir yukarı akışa itildiyse veya değişiklikler minimum olduğunda yapmalısınız, bu nedenle klonlama kurtarma işleminden daha hızlıdır.
mu 無

3

Benim durumumda, bu hata, tamamlama mesajını yazdığım ve not defterim kapalı olduğu için oluştu.

Hatayı düzeltmek için şu adımları gerçekleştirdim:

  • git checkout -b backup-branch # Yedek şube oluşturma
  • git reset --hard HEAD~4# Her şeyin iyi çalıştığı taahhüdü sıfırlayın. Benim durumumda, kafamda 4 taahhüdü geri almak zorunda kaldım, yani taahhüt mesajı yazmadan önce başım noktaya gelene kadar. Bu adımı uygulamadan önce, sıfırlayacağınız işlemlerin karmasını kopyalayın, benim durumumda son 4 işlemin karmasını kopyaladım
  • git cherry-pick <commit-hash> # Kiraz sıfırlanmış taahhütleri (benim durumumda 4 taahhüt vardır, bu yüzden bu adımı 4 kez yaptım) eski şubeden yeni şubeye.
  • git push origin backup-branch # Her şeyin yolunda gittiğinden emin olmak için yeni şubeyi itin
  • git branch -D your-branch # Şubeyi yerel olarak sil ('şubeniz' sorunlu şubedir)
  • git push origin :your-branch # Şubeyi uzaktan sil
  • git branch -m backup-branch your-branch # Yedek dalı, sorunu olan dalın adını alacak şekilde yeniden adlandırın
  • git push origin your-branch # Yeni dalı itin
  • git push origin :backup-branch # Yedekleme dalını uzaktan silme

3
git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

sorunumu çöz


bu yardımcı oldu. Teşekkür ederim.
swateek

Repo temizse, sadece "cd .git / && find. -Type f -empty -delete && cd - && git pull", bazı dosyaları git statusboş olduğundan bazı dosyaları teslim almanız gerekebilir .
CodyChan

2

İşte bu sorunla başa çıkmak için gerçekten çok basit ve hızlı bir yöntemdir EĞER size gerekli olan tüm şube ve kaydedilmesini ile yerel repo var ve yeni bir repo oluşturmak (veya sunucunun repo silme ve yenisini yapma berabersin Tamam eğer burada):

  1. Sunucuda yeni bir boş repo oluşturun (veya eski repoyu silin ve yerine yeni bir repo oluşturun)
  2. Yerel kopyanızın uzak URL'sini, yeni deponun uzak URL'sini gösterecek şekilde değiştirin.
  3. Yerel deponuzdaki tüm dalları yeni sunucu deposuna aktarın.

Bu, yerel repoda sahip olduğunuz tüm taahhüt geçmişini ve şubelerini korur.

Repo üzerinde ortak çalışanlarınız varsa, birçok durumda tüm ortak çalışanlarınızın tek yapmanız gereken yerel repolarının uzak URL'sini değiştirmek ve isteğe bağlı olarak sunucunun sahip olmadığı tüm taahhütleri itmek olduğunu düşünüyorum.

Aynı sorunla karşılaştığımda bu çözüm benim için çalıştı. Bir ortak arkadaşım vardı. Yerel repo'yu yeni uzak repoya ittikten sonra, yerel repoyu uzak repo URL'sini gösterecek şekilde değiştirdi ve her şey iyi çalıştı.


2

Zaten ona itilmiş tüm ilgili değişiklikleri içeren bir uzaktan kumandaya sahip olduğunuzu varsayıyorum. Yerel değişiklikleri umursamadım ve sadece büyük bir deponun silinmesini ve yeniden arşivlenmesini önlemek istedim. Önemli yerel değişiklikleriniz varsa daha dikkatli olmak isteyebilirsiniz.

Dizüstü bilgisayarım çöktükten sonra aynı sorunu yaşadım. Muhtemelen büyük bir depo olduğu için, arama yaparken sadece bir kerede görünen birkaç bozuk nesne dosyası vardı, bu git fsck --fullyüzden bunlardan birini otomatik olarak silmek için küçük bir kabuk tek astar yazdım:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

  • 2>&1 grep edebilmek için hata mesajını stdout'a yönlendirir
  • kullanılan grep seçenekleri:
    • -o bir çizginin yalnızca gerçekten eşleşen kısmını döndürür
    • -E gelişmiş normal ifadeleri etkinleştirir
    • -m 1 sadece ilk eşleşmenin iade edildiğinden emin ol
    • [0-9a-f]{2} ikisi birlikte oluşursa 0 ile 9 ve a ve f arasındaki karakterlerle eşleşir
    • [0-9a-f]* 0 ile 9 ile a ile f arasındaki karakterlerin herhangi bir sayısıyla eşleşir

Her seferinde yalnızca bir dosyayı siler, bu nedenle aşağıdaki gibi bir döngüde çağırmak isteyebilirsiniz:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Bununla ilgili sorun, artık yararlı bir şey çıkarmamasıdır, bu yüzden ne zaman bittiğini bilmezsiniz (bir süre sonra yararlı bir şey yapmamalıdır)

Bu "düzeltmek" için ben sadece git fsck --fullböyle her turdan sonra bir çağrı ekledi : $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Şimdi neredeyse yarısı kadar hızlı, ama "devlet" çıktı.

Bu bir noktaya kadar bu iplik önerilerle bazı etrafında oynanan ve son olarak aldıktan sonra nerede olabilir git stashve git stash dropkırık bir sürü şey.

ilk problem çözüldü

: Daha sonra ben hala şu sorunu vardı unable to resolve reference 'refs/remotes/origin/$branch': reference brokentarafından çözülebilir $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Sonra yaptım $ git gc --prune=now

$ git remote prune origin

iyi bir ölçü için ve

git reflog expire --stale-fix --all

error: HEAD: invalid reflog entry $blubbkoşarken kurtulmak için git fsck --full.


2

Basit gidelim .. sadece uzak git repo kaynağına yüklediğiniz durumda

  1. .Git'inizi yedekleyin
  2. git kontrol et

    git fsck --full
    
  3. boş nesne dosyasını kaldır (tümü)

    rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
    
  4. git'inizi tekrar kontrol edin.

    git fsck --full
    
  5. uzak git'ten kaynağını çek

    git pull origin master
    

2

Sanal makinelerde bu sorunla çok karşılaşıyorum.

Benim için aşağıdaki işler:

cd /path/to/your/project
rm -rf .git

Kendinize bazı indirmeler kaydetmek istiyorsanız - dosya gezginize gidin ve zaten taahhüt edilen klasördeki tüm dosyaları silin ve / vendor ve / node_modules (besteci ve npm ile çalışıyorum) klasörlerinizde bırakın.

o zaman yeni bir repo yarat

git init

uzaktan kumandanı ekle

git remote add origin ssh://git@github.com/YourUsername/repoName.git

ve şubeyi / hepsini getir

git fetch origin somebranch

ve kontrol et

git checkout somebranch

hatadan önceki noktada olmalısınız.

Bu yardımcı olur umarım.

Saygılarımızla.


1

Aynı sorunla karşılaşıyorum ve düzeltmek için çok basit bir yol kullanıyorum. Bu eksik dosyaların takım arkadaşımın bilgisayarında olduğunu gördüm.

Ben tek o dosyaları tek tek kopyalanan (9 dosya toplamı) bir git sunucuya ve bu sorunu giderildi.


1

Meslektaşlarım ve ben aynı problemle birkaç kez geçtik ve bunu çözmek için aşağıda tarif ettiğim adımları atıyoruz. Bulunabilecek en zarif çözüm değil, ancak veri kaybı olmadan çalışır.

  1. Geçerli çalışma dizinini yeniden adlandırın. ( old_projectbu örnek için).
  2. Kullanarak yeni bir dizin içindeki havuzu klonlayın git clone.
  3. Komut satırında, çalışma dizinini yeni oluşturulan projeyle değiştirin ve üzerinde çalıştığınız şubeye geçin.
  4. İçindeki tüm dosya ve dizinleri kopyala old_project(.git ) yeni oluşturulan proje dizinine .
  5. Çalışma ağacı durumunuzu kontrol edin (beklediğinizden çok daha fazla değişiklik olduğunu unutmayın) ve ardından değişiklikleri yapın.

Umut ediyorum bu yardım eder...


1

İşte github.com'daki genel repo çalışıyorsanız, ancak yerel repo bozuksa sorunu çözmenin bir yolu. Yerel repoda yaptığınız tüm taahhütleri kaybedeceğinizi unutmayın.

Tamam, bu yüzden bana bunu veren bir repo var object empty error, ve aynı repo github.com, ama bu hata olmadan. Yani basitçe yaptığım şey, github'dan çalışan repo'yu klonlamak ve daha sonra her şeyi bozuk repo'dan (.git klasörü hariç) kopyalamak ve çalışan klonlanmış repo'yu yapıştırmaktı.

Bu pratik bir çözüm olmayabilir (yerel taahhütleri sildiğiniz için), kodu ve onarılan bir sürüm denetimini korursunuz.

Bu yaklaşımı uygulamadan önce yedeklemeyi unutmayın.


1

Benim durumumda, yerel taahhüt geçmişini korumak benim için önemli değildi. Bu sizin için de geçerliyse, bunu yukarıdaki çözümlere hızlı bir alternatif olarak yapabilirsiniz:

Temel olarak bozuk .git/dizini temiz bir dizinle değiştirmeniz yeterlidir .

Projeniz için bozuk git ile aşağıdaki dizini varsayalım: projects/corrupt_git/

  1. cp projects/corrupt_git projects/backup - (isteğe bağlı) yedekleme yapın
  2. git clone [repo URL] projects/clean_git - böylece projects/clean_git
  3. rm -rf corrupt_git/.git/ - bozuk .git klasörünü kaldırın
  4. mv clean_git/.git/ corrupt_git/ - temiz git'e git corrupt_git/.git
  5. git statusiçinde projects/corrupt_git- emin olmak için işe yaradı

0

Her şeyi (.git içeren klasörde) bir yedeğe kopyalayın, ardından her şeyi silin ve yeniden başlatın. Git uzaktan kumandasının elinizde olduğundan emin olun:

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

Sonra

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

Ardından yeni dosyaları el ile birleştirin ve bilgisayarınızı açık tutmaya çalışın.


rm -rf * çok kötü sonuçlara yol açabilir . Gerçekten bunu mu demek istediniz?
tommyk

@tommyk bu nedenle önce yedek kopya. Sanırım güç gerekli değil.
Shelvacu

0

Temiz bir daldan master kontrol ettikten sonra aynı sorunu vardı. Bir süre sonra master'da birçok değiştirilmiş dosyayı tanıdım. Temiz bir daldan geçtikten sonra neden orada bulunduklarını bilmiyorum. Her neyse, değiştirilmiş dosyalar benim için bir anlam ifade etmediği için onları sakladım ve hata gitti.

git:(master) git stash


0

ESKİ yedeklemeniz varsa ve aceleniz varsa:

mevcut, git-broken, proje yolunuzda YENİ YEDEKLEME yapın.

  1. Hamleni .git(silme asla) çöp kutusuna
  2. .gitOLD yedeklemesinden kopyala
  3. git pull (birleştirme çakışmaları oluşturur)
  4. tüm kaynaklarınızı (git'e koyduğunuz her şeyi) çöp kutusuna taşıyın: ./src (asla silmeyin)
  5. .NEDEN YEDEKLEME'den tüm kaynaklarınızı (git'e koyduğunuz her şeyi) kopyalayın
  6. tüm "birleştirme" kabul git gui, itme ve ... ellerini çırp!

0

Yukarıda anlatılan on iki aşamalı çözüm, bir reçelden kurtulmama da yardımcı oldu. Teşekkürler. Anahtar adımlar girmekti:

git fsck --full 

ve tüm boş nesneleri kaldırın

rm .git/objects/...

Sonra flogun iki satırını almak:

tail -n 2 .git/logs/refs/heads/master

Döndürülen değerlerle

git update-ref HEAD ...

Bu noktada artık hatam olmadı, bu yüzden en son dosyalarımın bir yedeğini aldım. Sonra bir git ve ardından bir git itme yapın. Yedeklerimi git depo dosyama kopyaladım ve başka bir git push yaptı. Bu beni güncel kıldı.


0

Git hatamı düzelttim: nesne dosyası boş:

  1. Son başarılı taahhüdüm / push'umdan bu yana düzenlediğim tüm dosyaların bir kopyasını kaydetme,
  2. Depomun kaldırılması ve yeniden klonlanması,
  3. Eski dosyaları düzenlenmiş dosyalarımla değiştiriyorum.

Umarım bu yardımcı olur.


0

Bu da neredeyse düzenli olarak başıma geliyor. Bu tam olarak gerçekleştiğinde bir protokol yapmadım, ancak sanal makinem "beklenmedik bir şekilde" mevcut olduğunda gerçekleştiğinden şüpheleniyorum. VM penceresini kapatırsam (Ubuntu 18.04 kullanıyorum) ve yeniden başlatırsam, işler her zaman (?) İşe yarar. Ancak dizüstü bilgisayarım kapatıldığında VM penceresi hala açıksa (Windows ana bilgisayar sistemi), bu sorunla sık sık karşılaşıyorum.

Burada verilen tüm cevaplara gelince:

  1. teşekkür ederim - çok faydalılar; Genellikle kodumun yerel bir kopyasını kaydederim, repoyu uzaktan geri yüklerim ve yedek kopyayı tekrar yerel klasöre taşırım.

  2. altta yatan problem gerçekten bir git sorunu değil, bir VM ve / veya Linux sorunu olduğundan, belirtileri değil, nedeni tedavi etmenin bir yolu olup olmadığını merak ediyorum? Bu tür bir hata, bazı dosya sistemi değişikliklerinin makul bir zamanda "uygulanmadığını", ancak yalnızca önbelleğe alındığını göstermez mi? (örneğin, /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - bana sanal Linux makineleri gelmiyormuş gibi görünüyor sık sık onların şeyler fsynch. Bu, Oracle'ın VirtualBox (aksi halde çok iyi çalışır) veya konuk dosya sistemi veya hepimizin göz ardı ettiği bazı ayarların bir sorunu olup olmadığı uzmanlığımın ötesindedir. Ama birisi buna ışık tutabilirse mutlu olurum.


0

Aslında aynı problemi yaşadım. Bunu denemeden önce kodunuzun bir kopyasını alın.

az önce yaptım git reset HEAD~

son görevim geri alındı, sonra tekrar taahhüt ettim, sorun çözüldü!


-5

Uyarı: Daha fazla tecrübeyle, bunun nükleer seçenek olduğunu ve tipik olarak yapılmaması gerektiğini ve hiçbir şey öğretmediğini anlıyorum. Ancak, kişisel projeler için nadiren de olsa, hala yararlı buldum, bu yüzden bırakıyorum.

Tarihsel taahhütlerinizi tutmayı umursamıyorsanız, sadece koşun

rm -r .git

Sonra yazmaya karşı korumalı dosyaları silmekle ilgili sorulara evet yanıtı verin. Sorun bir dakika içinde çözüldü.


3
Geçmişinizi incelikli yapmak istiyorsanız bunu yapmayın.
mu 無
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.