Git gc fatal ile nasıl başa çıkılır: kötü nesne başvuruları / uzaktan kumandalar / kaynak / HEAD hatası?

131

Bugün Git çöp toplama işlemini çalıştırmaya çalışırken buna rastgele vurdum :

$ git gc
fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Bununla nasıl başa çıkacağım?

— Ryan
kaynak

163

Bunun sonuçlarını anlamıyorum, ancak bu ileti dizisinde önerildiği gibi, bununla karşılaştığımda anladım

$ mv .git/refs/remotes/origin/HEAD /tmp

(her ihtimale karşı etrafta tutmak) ve sonra

$ git gc

şikayet etmeden çalıştı; Herhangi bir sorunla karşılaşmadım.

— petrelharp
kaynak

6

Benim için çalıştı ve sanırım bu soruna girdim çünkü varsayılan şubeyi masterdenilen başka bir şubeye değiştirdim develop. Eski varsayılan dalı olarak developdeğiştirmeden masterve eski varsayılan dalı sildimdevelop , ancak çalışma dizinimde dosya .git/refs/remotes/origin/HEADhala refs/remotes/origin/developmevcut olmayan bir yere işaret ediyordu . Bu durumda dosyanın kaldırılması işe yaradı.

— Stavarengo

4

git prunebenim için çalıştı, Git'te biriken ancak yararlı hiçbir şey tarafından referans alınmayan verileri silmenin bir yolu.

— Sven Malvik

Onları $ mv .git/refs/remotes/origin/HEAD /tmp $ git gc git prune

— idam etmek

2

En iyi yolun WilQu'nun cevabı ( stackoverflow.com/a/49944297/660339 ) olacağından şüpheleniyorum . Bunu doğrulayan var mı?

— Ivan Perez

bu dosyayı .git klasöründen kaldırmak, git gcbenim için çalıştığından daha

— Vino

68

Karşılaştığım sorun ( yukarıdaki bu yorumda belirtilen @Stavarengo'nun aynı sorunu ), varsayılan uzak şubenin ( developbenim durumumda) silinmiş olması, ancak yine de .git/refs/remotes/origin/HEAD.

.git/refs/remotes/origin/HEADEditörümde açılış şunu gösterdi:

ref: refs/remotes/origin/develop

Ben dikkatle benim yeni varsayılan şubesinde noktaya düzenlenebilir ve tüm iyi oldu:

ref: refs/remotes/origin/master

Beni bilgilendiren ipucu, koşmanın git pruneşu hatayı göstermesiydi:

> git prune
warning: symbolic ref is dangling: refs/remotes/origin/HEAD

— Trenton
kaynak

1

Bu benim de düzeltmemdi

— Dan Carlstedt

1

Bu benim kesin çözümümdü. Ekibimiz kısa süre önce varsayılan şube geliştirmeyi kullanmaktan ustalaşmak için değiştirildi

— jmancherje

40

Trenton'un cevabını gördükten sonra, kendime baktım .git/refs/remotes/origin/HEADve şimdi silinmiş olan eski bir dalı işaret ettiğini gördüm.

Ancak dosyayı kendim düzenlemek yerine Ryan'ın çözümünü denedim:

git remote set-head origin --auto

Dosyayı otomatik olarak yeni şubeye ayarladı ve git gcbundan sonra iyi çalıştı.

— WilQu
kaynak

Evet, bu benim için çalışıyor - tıpkı aynı senaryoda olduğu gibi. git remote set-head $REMOTE --autobenim durumumda, $ REMOTE uzak diğer addır, varsayılan "kaynak" değil, çünkü birden fazla uzaktan kumanda kurulumum var.

— Devy

29

Bunun işe yarayacağı için çözümün aşağıdaki olduğunu düşündüm, ancak aslında sorunu çözmediği ortaya çıktı.

git remote set-head origin --auto

— Ryan
kaynak

1

Görünüşe göre bu komut aynı dertten kurtulmama yardımcı oldu. Bununla birlikte, bu komuttan sonra, ben de kullandım git prune(ilk komut çıktısında önerildiği gibi), bu yüzden bana neyin yardımcı olduğunu tam olarak söyleyemiyorum - birinci, ikinci veya her ikisi.

— Borys Pylhun

1

git remote set-head origin --autorefs / remotes / origin / HEAD git prune

— dosyamı

Bu hatayla karşılaştım: error: Multiple remote HEAD branches. Please choose one explicitlyve hatanın git remote set-head origin mybranchortadan kalkması için ('şubem' şubesi kontrol edilirken) kullanmak zorunda kaldım .

— derekmx271

3

Olumsuz oylama, çünkü tam bir cevap değildir ve yanıltıcı olabilir.

— Christian Vielma

9

Görünüşe göre sembolik referanslarınız bozuk olabilir ... Bunu varsayılan dalınızla değiştirmeyi deneyin: Örneğin, benim varsayılan dalım ana

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master
$ git fetch --prune
$ git gc

Bu onu düzeltmeli.

— Conal Trinitrotoluene Da Costa
kaynak

0

Git çalışma ağaçları kullanıyorsanız,

git worktree prune

koşmadan önce

git gc

Bir çalışma ağacım bozuldu ve bu, bozuk çalışma ağacını çıkardıktan sonra hile yaptı. git prunekendi başına işe yaramadı.

— JeffP
kaynak

0

Bunun benim için nedeni Windows'ta sıkıştırılmış bir klasörde çalışmaktı. Klasör sıkıştırılmamış haldeyken, var olmayan dalları budayamamak gibi diğer garip sorunları basamaklayarak paket dosyalarını bozdu.

Tek düzeltme, çalışma dizinini silmek ve depo uzak (lar) ını tekrar klonlamaktı. Neyse ki, hiçbir şeyin kaybolmadığından emin olmak için güncellemeleri almaya ve çekmeye devam edebilirim. Şimdi her şey yolunda.

— Will Strohl
kaynak