Git nesne yazarken takılıyor


105

Deniyorum ve git push -u origin mastersadece takılıyor

Writing objects:  99% (219/220), 12.65 MiB | 97 KiB/s

12.65Bölüm etrafında kayar. İşlemden çıkıp tekrar çalıştırdığımda,% 99'da devam ediyor ama daha önce olduğu gibi asla bitmiyor.

Asla başarılı bir şekilde itilmedi. Bu ilk işlemdir.


Nereye itmek istersiniz? SSH veya başka bir protokol kullanıyor musunuz?
Paŭlo Ebermann

27
http.postbufferYardımı ayarlamak mı? stackoverflow.com/questions/6842687/…
VonC

3
VonC'nin yorumunu gözden kaçırmak çok kolaydır. Benim için çalışıyor.
Thuan

1
Inanılmaz. Bu benim için de yaptı. Ve şimdi 2018. Ve bu SSH, HTTP değil. Ve deponun tamamı 15MB gibi. Ve "uzak" sunucu localhost'tur. Git'i romantize etmeyi bırakın millet, lütfen! ;)
Sz.

Yanıtlar:


227

VonC'nin tavsiyesine uydum:

git config --global http.postBuffer 524288000

Gelecekteki referanslar için yorumlara dayalı olarak:

500 MB: 524288000 (as posted in the original answer)
1 GB: 1048576000
2 GB: 2097152000 (anything higher is rejected as 'out of range')

4
Aman tanrım, bunun için teşekkürler! saçımı çekiyordu ve bu sorunlarımı çözdü!
Brett Thomas

3
@HugoForte Arabelleği artırmak, asılı dosyalarımın yazımını çözüyor gibi görünüyordu, ancak git itme işlemim asla tamamlanmadı (askıda kaldı Writing objects: 100%) - daha önce% 25'te asılıydı, bu yüzden bu açıkça yardımcı oldu. Ancak yine de "tuhaf" davranışlar alıyordum. Ben sistemimi yeniden ve bu çözümleme şeyler gibiydi ... Bilginize ... Herkes hala benim konuda çok yardımcı sistemimi (eski okul çözüm hiçbiri az ama taze yeniden başlatma gerçekten yardımcı) yeniden başlatarak, onların tampon artan sonra da sorun ulaşıp ulaşmadığını.
twknab

4
Numaranın 524288000nereden geldiğini açıklayan var mı?
Ryre

7
@Ryre 500 MB
Hugo Forte

1
Tanrı seni ve Stackoverflow'u korusun, onsuz tamamen kaybeden olurdum,
decoder7283

38

Bu, repo dizinindeki büyük, imzasız dosya nedeniyle oluyordu. Hata.

DÜZENLE

Asılmanın nedeni dosyanın yüklenmesi uzun sürüyordu. Dosyanın itmeye dahil edilmemesi gerekiyordu.

DÜZENLE

Bu doğru olsa söz konusu dosyayı görmezden ya da sadece olamazsa büyük dosya, bu konuda nedeni olabileceğini var o zaman izleyin itmek için bu cevabı.


@TimoSolo Bunu neden yapayım? Sorun olan bendim ve tam olarak düzeltmeyi belgeledim. Oldukça basit.
mattalxndr

4
Evet, düzeltmeniz sorunu ortadan kaldırmaktı. Gerçekten büyük bir dosyayı itmesi gereken diğer insanlar uğruna, @ hugo-forte'un cevabı sorunu çözer. Sen yok olması SO ruhunda - Ben daha fazla insana yardımcı olacağını düşündük için.
TimoSolo

2
Soru "Nasıl işleyip sonra da büyük bir dosyayı itebilirim?" Değil. "Git zorlamam hiç bitmiyor. Neden?" Zorlamanın sonsuza kadar sürmesini beklemiyorsanız, muhtemelen (benim gibi) o büyük dosyayı işlemek istemediniz.
mattalxndr

3
@mattalxndr Kabul edilen cevap 1/8 oy aldığında, muhtemelen değiştirmelisiniz.
NorCalKnockOut

1
@mattalxndr Hiçbir cevap mükemmel değil. Biri sebebi belirler ve diğeri bir çözüm sunar. İdeal cevap, nedeni tanımlayacak, neden verilen sonuca sahip olduğunu açıklayacak ve iki alternatif çözüm sunacaktır. IMO, mevcut seçenekler dışında, Hugo Forte'nin cevabı daha üstün çünkü dosyayı itmek isteyip istemediğinize bakılmaksızın sorunu çözecektir. Sizin yaptığınız aynı hatayı yapan insanları görmezden gelmek değil; sorunu başkaları kadar onlar için de düzeltir, ancak istemedikleri takdirde bir dosyayı kaldırmayı onlara bırakır.
BZ1

7

Aynı problemi (% 16 nesneleri yazarken) takılıp sonra ölümle yaşadım. Bunu mevcut değişiklikleri kaydedip yeni bir depoyu klonlayarak, ardından değiştirilen dosyaları buraya kopyalayarak çözdüm.

Örneğin. Mevcut deponun A olduğunu varsayalım, o zaman yapmanız gereken tek şey:

  1. mv A B
  2. git clone A
  3. mv B/* A/
  4. rm -rf B

Sonra taahhüt edin ve itin ve her şey yolunda gitti. Taşınan dosyaları değiştirilmiş olarak tanıdı :)


Farklı bir belirti yaşıyordunuz. Benimkinde ölümcül bir hata yoktu.
mattalxndr

5

Benim durumumda, depo ile aynı sürücüde saklanan kötü haklara sahip bir git klasörü kullanıyordum, ancak yetkili bir oturum açma kullanıcısı kullansanız bile ssh ile aynı olabilir.

Uzak depoya yazmak için doğru haklara sahip olup olmadığınızı kontrol edin.

Misal:

Yerel ve uzak repo başlat

git init /tmp/src
git init --bare /tmp/dst
cd /tmp/src

Uzak depoyu kaynağa ekleme

src > git remote add dest /tmp/dst

Simülasyon problemi

src > chmod -R 555 /tmp/dst

Sahte dosya eklemek ve itmek

src > touch a && git add a && git commit -m 'demo'
src > git push --set-upstream dest master
src > git push
Counting objects: 3, done.
Writing objects: 99% (2/3), 202 bytes | 0 bytes/s.

Git takılıyor

Çözüm

src > chmod -R 775 /tmp/dst

2
Lütfen cevabınıza birkaç örnek ayrıntı daha eklemeyi düşünün, teşekkürler.
Mirza Sisic

1
Afedersiniz. Daha iyi mi ?
Naewis

3

Benim durumumda dosyanın boyutuydu. Gerekli uzantılara sahip bir .gitignore dosyası ekleyerek, itilecek istenmeyen dosyaların çoğunu görmezden gelebildim.



1

git clean -f -nsorunumu çözer. Algılanmayan birçok izlenmemiş dosya var. Ancak dikkatli olun çünkü bu, dizininizdeki dosyaları kaldıracaktır.


3
Özellikle hangi dosyaları kaldıracak?
Jazimov

1

Benim durumumda, şirket kurallarını tamamlamadan zorlamaya çalışıyordum. Daha sonra, commit mesajlarımıza "MOBIL-XXXX" ile başlamamız gerektiğini öğrendim; burada XXXX, geliştiricilerin Jira'da (geliştirme sürecini izlemek için kullandığımız başka bir araç) atanan sayıdır.

Şirketinizin benzer bir kısıtlama kuralı olup olmadığını kontrol ettiğinizden emin olun.


0

Windows 10 makinesinde aynı sorunu yaşıyordum writing objects, asılıydı, ancak biraz farklı bir durumda.

Yaşadığım sorun yalnızca arşive yeni dosyalar eklemeye çalıştığım zamandı. Depoda zaten mevcut olan dosyaları güncellersem, her şey iyi çalışıyordu ve dosya boyutunun büyük olup olmaması gerçekten önemli değil. Çoğunlukla yeni komut dosyaları eklemeye çalışıyordum.

İnternette bulunan diğer tüm çözümleri denedim ama benim durumumda hiçbir şey işe yaramadı ve denediğim son şey gerçekten işe yaradı. Görünüşe göre, bir yönetici hesabıyla oturum açtığımda ve uygulamayı yönetici olarak çalıştırdığımda bile, uygulamanın bu belirli klasörlere yazmasını veya dosyaları güncellemesini engelleyen belirli sürücü ve klasör için bazı Windows izinlerinden kaynaklanıyordu. Yani bu komut:

attrib -r +s D:\foldername 

sorunu benim için düzeltti.

Sadece buraya gönderiyorum, belki birisinin sorunu benimkiyle aynıdır.

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.