Git 'ölümcül: Yeni dizin dosyası yazılamıyor'

Bununla ilgili diğer konuların çoğunu gördüm ve yardımcı olmuyorlar.

Çok basit bir depom var - iki JavaScript dosyası. Macbook'ta 100 GB'ım var. Dosyaları bir alt dizine taşımaya çalıştığımda ve aldığım değişiklikleri yerel olarak hazırladığımda ...

ölümcül: Yeni dizin dosyası yazılamıyor

Bu, tüm eylemleri terminalde yapsam veya SourceTree gibi bir GUI kullandığımda olur. Ek olarak, dosyalardan biri kilitlendi ve oturumu kapatıp tekrar açana kadar çalışma dizinini silemiyorum.

Bu neden oluyor? Kilit bir şeyin evrelenmesini engelliyor mu? Öyleyse, OS X'te sorunlu dosyanın kilidini nasıl / nasıl açabilirim? Uzaktan repo, Google Code'dur, eğer bu bir fark yaratırsa, henüz uzaktan kumandaya zorlamıyorum. Her şey yereldir.

Benim durumumda diskte yer kalmadı, bu yüzden yer açmak için dosyaları sabit sürücüden silmem gerekti.

Son birkaç gündür aynı sorunu yaşıyorum. Temel olarak, bilgim olmadan tüm depo yeni bir dosya sistemine taşındı, git durumunu çalıştırmayı denediğimde, aniden depodaki her dosyanın udpated edildiğini bildiriyordu.

Olası çözümler

Bu yüzden, çok fazla google taramasından sonra aşağıdakileri denedim:

• .git izinlerini değiştirme (aynı sorun)
• .git / index izinlerini değiştirme (aynı sorun)
• git uygulamak için tüm değişiklikleri ekleme (aynı sorun)
• git rm-ing, dosya adı çok uzun hatalar bildirdikleri için silinen dosyalar (aynı sorun)
• git reset (yumuşak | Baş | Zor) (aynı sorun)
• git clean (aynı sorun)
• Windows savunucusunu kapatmak (aynı sorun)
• git güncelleme (aynı sorun)
• farklı git istemcileri (gitbash kullanıyorum) (aynı sorun)
• 1 yerine 2 kahve içmek (aynı sorun)

tl: dr - kirli çözüm

Sorunu çözmeyi başaran tek şey, dizin dosyasını kopyalamak, orijinali silmek ve kopyayı yeniden adlandırmaktı.

Bunun gerçekten bir 'çözüm' olmadığını biliyorum ama şimdi sihirli bir şekilde çalışıyor> <, tüm dosyalar / dallar bozulmadan. Bunun neden işe yaradığını bilen biri varsa, söyle.

Benim durumumda, dropbox senkronizasyonunu duraklatmak sorunu çözdü

Mac'te de aynı sorunu yaşadım. Dosya sistemi ACL'lerinden kaynaklanıyor gibi görünüyor. chmod -RN /path/to/repoACL'leri temizlemeye çalışın . Bunu yaptıktan sonra değişiklikler yapabildim. Dizin dosyasını kopyalamak için hile kullanarak, orijinali silin ve kopyayı geri taşıyarak aynı sonucu elde edin.

Github kurulumunuz, google drive veya dropbox gibi bir tür çevrimiçi senkronizasyon hizmetinde varsa, senkronizasyon hizmeti, github aynı şeyi yapmaya çalışırken github'ın çalışmamasına neden olduğu için senkronizasyonu devre dışı bırakmayı deneyin. doğru şekilde.

.Git / index dosyası başka bir işlem tarafından kullanılıyordu (yerel geliştirme web sunucum). Süreci kapattım ve sonra işe yaradı.

Visual Studio Kodunu kapatmak (benim durumumda dosya kaydetmede çalışan bir otomatik yükleyici arka plan işi var) sorunu benim için çözdü.

Çözüm için kredi: arkadaşım ve meslektaşım Arnel.

Bu benim için çalıştı:

rm -f ./.git/index.lock

Benim durumumda, çözüm sadece yeni kullanıcıya izin eklemekti.

Yeni işletim sistemi kurduğumda, depolarımı taşıdığımda ve tam olarak bu hatayı gösteriyordu Kök klasörünü seçtim ve ardından hepsini kontrol etmek için kullanıcının kimliğini doğruladım

.Git klasöründeki tüm dosyalara ACL (bir şekilde) ekledim.

ls -le.Git klasöründe kontrol edin .

ACL'yi chmod -N(bir klasör / dosya için) veya chmod -RN(özyinelemeli) ile kaldırabilirsiniz.

Google Yedekleme ve Senkronizasyon gibi bazı arka plan yedekleme çözümlerinin dizin dosyasına erişimi engellediğini düşünüyorum. Uygulamayı kapattım ve Sourcetree'nin hiç sorunu olmadı. Dropbox'ın da aynı şeyi yaptığı görülüyor (@tonymayoral).

Benim durumumda eşzamanlı çalışan bir EGit idi. Tutulmayı yeniden başlattıktan sonra her zamanki gibi çalışır.

Bir Windows kutusundaysanız, ister Kaynak Ağacı ister bir git terminali olsun, kullandığınız programın yönetici olarak çalıştığından emin olun. Aynı hata mesajını alıyordum. Yönetici olarak çalıştırmak için programa sağ tıklayabilir veya özelliklerini her zaman yönetici olarak çalışacak şekilde değiştirebilirsiniz.

Yeterli alana sahip olmamak bir sorundur. Temizle ve tekrar dene

Ben de aynı sorunu yaşadım. Bilgisayarımı yeniden başlattım ve sorun çözüldü.

'git add' denedin mi? . tüm değişiklikler olacak mı? (gereksiz eklenen dosyaları git reset HEAD ile kaldırabilirsiniz)

Hata mesajı fatal: Unable to write new index file, yeni içeriği git indeks dosyasına yazamadığımız anlamına gelir .git\index( git indeksi hakkında daha fazla bilgi için buraya bakın ). Bu sorunun tüm cevaplarını inceledikten sonra, aşağıdaki temel nedenleri özetledim:

• Yeni içeriğin boyutu, kullanılabilir disk kapasitesini aşıyor. ( Çözüm : Disk alanlarını temizleyin)
• Kullanıcıların bu dosyaya erişim hakkı yoktur. ( Çözüm : İzin verin)
• Kullanıcıların izni vardır ancak .git\indexdiğer kullanıcılar veya işlemler tarafından kilitlenir. ( Çözüm : Dosyanın kilidini açın)

Windows'ta hangi işlemin bir dosya veya klasörü kilitlediğini bul bağlantısı , belirli bir dosyayı kilitleyen işlemi bulmak için aşağıdaki yaklaşımı belirtir:

SysInternals Process Explorer - Bul> Tanıtıcı veya DLL Bul seçeneğine gidin. "Tutamaç veya DLL alt dizesi:" metin kutusuna dosyanın yolunu yazın (örneğin "C: \ yol \ - \ dosya.txt") ve "Ara" düğmesini tıklayın. Bu dosya için açık bir tanıtıcıya sahip olan tüm işlemler listelenmelidir.

Hangi işlemin kilitlendiğini bulmak için yukarıdaki yaklaşımı kullanın .git\indexve ardından çalıştırılabilir kilitlemeyi durdurun. Bu kilidi açar .git\index.

Örneğin, İşlem Gezgini Araması , bunun .git\indextarafından kilitlendiğini gösterir vmware-vmx.exe. VMWare Player sanal makinesinin (git deposuna paylaşılan bir klasör aracılığıyla erişen) askıya alınması sorunu çözdü.

BİR REBASE SIRASINDA BUNU ALIRSANIZ:

Bu büyük olasılıkla yedekleme yazılımı, anti-virüsler, IDE'ler veya diğer git istemcileri gibi deponuzun dizin dosyasını kilitleyen bazı yazılımlardan kaynaklanır.

Çoğu durumda, kilit sadece kısa bir an içindir ve bu nedenle, kötü zamanlama ve şanssızlık nedeniyle olur.

Ancak, bir git rebase --continuesonraki komutun boş bir commit olmasından şikayet edecek:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Bunu düzeltmek için koşup tekrar git resetdeneyin git rebase --continue.

Sorun: Git'te bazı değiştirilmiş dosyaları kontrol ederken bu hatayı aldım. ABC ve XYZ olmak üzere iki kullanıcım vardı. dosyaları ABC'nin uid: gid'ine sahip, ancak git erişimine sahip değil ve dosyaları aynı şekilde teslim almaya çalışıyor.

Denediğim çözüm: XYZ git erişimine sahip, sudo ile dosyaları kontrol etmeyi denedi ve işe yaradı .. !!

İşte benim için işe yarayan şey:

Bağlam:

1. Bir sunucuda proje oluşturma

2. git status döndürür HEAD detached at <commit-SHA>

3. Yerel olarak yaptığım işlem ne olursa olsun, bu hatayı aldım. Daha spesifik olarak:

   • git checkout
   • git sıfırlama KAFA - sert

Çözüm

1. Basitçe kaldırılan dosya <work-dir>/.git/index.
2. A git status, projetteki tüm dosyaların izlenmediğini gösterir (burada şaşırtıcı değil).
3. git reset HEAD --hard
4. A HEAD detached at <commit-SHA>yaptığın zamana geri dön git statusama sonra yapabilmelisin
5. git checkout <some-branch>

ve yolunuza geri döndünüz!

!! ÖNEMLİ !!

Bu sadece "sadece" inşa ettiğim için işe yarıyor. Kodda hiçbir değerli değişiklik yapılmadı. Gerçekte "geliştirme zamanı" içindeyseniz, önce çalışmanızı kaydetmenizi veya başka bir yönteme geçmenizi tavsiye ederim.

Umarım yardımcı olur :).

Pencerelerde GitExtensions kullanırken bu sorunu yaşadım. Depoyu içeren klasörde mevcut kullanıcıya (ben) tam izin verilmesi ile düzeltildi.

Başka bir sefer, Git Extensions'tan hatayı alsam da, aynı dosyaları Visual Studio 2015'ten işleyebildim.

Başka bir sefer "dizin" dosyasını .git klasöründen silmek zorunda kaldım

Durumum biraz ilginç:

Belirli bir commit'i kontrol etmek için git log çalıştırıyorum, sonra düzgün şekilde çıkmadım, çıkmak için ctrl + c tuşlarına basıyorum.

Sonra dizin kilitlenmiş görünüyor. Bu yüzden git log'u tekrar çalıştırıyorum, ardından çıkmak için Q tuşuna basıyorum.

Problem çözüldü. :)

Benim durumumda nodemon, değişiklikler için dosya sistemini izleyen bir örnekti.