git çekme, dosya adı hatası nedeniyle iptal edildi çok uzun


114

İşletim sistemim olarak Windows'u kullanıyorum ve Mac kullanan bir arkadaşımla bir proje üzerinde çalışıyorum. Github'ımızın kodunu kontrol etti.

Yaptığı her şeyi çekmeye çalışıyordum ve 3. parti kodunun "dosya adı çok uzun" hatalarıyla iptal edildi.

Ne yapabilirim?


Bu sorunun, operasyonunuza bağlı olarak iki temelde farklı durumu vardır. Depo zaten mevcutsa, yapılandırmasını düzenleyebilirsiniz. Ama eğer olmazsa? Yeni bir dizin oluşturarak klonlama / kullanıma alma için yalnızca @AlexRosenfeld'in yanıtı yardımcı olacaktır.
Gangnus

Yanıtlar:


200

Git'teki msysgit SSS'si, eski msysgit bileti # 110'a hala bağlantı oluşturduğundan, uzun bir yol içeren bir dosya yönlendiricisi oluşturamıyor, güncel görünmüyor . Ancak, daha sonraki 122 numaralı bilete göre , sorun msysgit 1.9'da düzeltildi, bu nedenle:

  1. Msysgit 1.9'a (veya daha sonra) güncelleme
  2. Git Bash'i başlatın
  3. Uzun yollar sorunu 'çeken' Git deponuza gidin
  4. Uzun yollar desteğini etkinleştirin git config core.longpaths true

Şimdiye kadar benim için çok iyi çalıştı.

122 numaralı biletle ilgili yorumdaki önemli nottan haberdar olun

buraya geri dönmeyin ve Windows Gezgini, cmd.exe, bash veya kullandığınız her türlü aracı bozduğundan şikayet etmeyin.


Birkaç güncelleme var gibi görünüyor, mysysgit github.com/msysgit/git/pull/122#issuecomment-43653756
Adam Grant

18
Aslında işe yarayan şey şuydu: git config --global core.longpaths true
Anton Andreev

@AntonAndreev Evet, global kapsamda ayarlamak isterseniz, sorun değil. Depo başına yerel kapsam da tamamen geçerlidir.
mloskot

Küresel seviyeye getirmeden benim için işe yaramadı.
Anton Andreev

1
Bu yol, yeni bir dizin oluştururken klonlama / kullanıma alma için çalışmaz. Sadece @AlexRosenfeld'in cevabı yardımcı olacaktır.
Gangnus

69

1.Çözüm - Bu komutu çalıştırarak genel yapılandırmayı ayarlayın:

git config --system core.longpaths true

Çözüm2 - veya özel git yapılandırma dosyanızı aşağıdaki gibi doğrudan düzenleyebilirsiniz:

YourRepoFolder -> .git -> yapılandırma:

[core]
    repositoryformatversion = 0
    filemode = false
    ...
    longpaths = true        <-- (add this line under core section)

3. Çözüm - yeni bir depo klonlarken: burada .


1
Bu yol, yeni bir dizin oluştururken klonlama / kullanıma alma için çalışmaz. Sadece @AlexRosenfeld'in cevabı yardımcı olacaktır.
Gangnus

Cevabı bununla güncelledim, tek bir yerde olması için teşekkürler.
Daniel Hári

26

Birkaç yıl geç, ancak bunu bir hamlede yapmanız gerekiyorsa (benim yaptığım gibi), klon komutu sırasında yapılandırma ayarlarını yapabileceğinizi eklemek isterim. Bunu dene:

git clone -c core.longpaths=true <your.url.here>

1
Şerefe arkadaşlar! Bu, github'dan yeni bir dizin klonlarken harika çalıştı.
Jay Killeen

Hiç sorun olmadı, iyi ki yardımcı oldu!
xandermonkey

1
Evet! Bu ve klonlama için - sadece bu çalışıyor!
Gangnus

Bu işe yaramıyor, klonlamam hala iptal ediliyor. Kullanıyorum git version 1.8.4.msysgit.0, herhangi bir fikrin var mı?
Simple-Solution

Görünüşe göre bu kullanımdan kaldırılmış . Belki git-scm kullanmayı deneyin ? Hangi hatayı alıyorsun?
xandermonkey

12

Longpaths özelliğini eklemek için.gitconfig dosyanızı açın. Yani aşağıdaki gibi görünecek:

[core]
symlinks = false
autocrlf = true
longpaths = true

1
Bu yol, yeni bir dizin oluştururken klonlama / kullanıma alma için çalışmaz. Sadece @AlexRosenfeld'in cevabı yardımcı olacaktır.
Gangnus

6

Windows'ta java depoları ile sürekli olarak bu problemle karşılaşan biri olarak, en iyi çözüm Cygwin'i ( https://www.cygwin.com/ ) kurmak ve git kurulumunu all> devel> git altında kullanmaktır.

Bunun karşılaştığım en iyi çözüm olmasının nedeni, Cygwin'in uzun yol adlarını yönetmesi ve böylece sağlanan diğer komutların fayda sağlamasıdır. Ör: find, cp ve rm. İnanın bana, asıl sorun Windows'ta çok uzun olan yol adlarını silmeniz gerektiğinde başlar.


4

Dosyalarınızı dosya sistemi köküne yakın tutmaya çalışın. Daha fazla ayrıntı: teknik nedenlerle, Git for Windows, mutlak yol 260 karakterden uzun olduğunda dosya veya dizin oluşturamaz .


Görünüşe göre sadece 130'a gidebilir [belki Windows altında çift baytlı unicode karakterler kullanır] varsayılan olarak [?]
rogerdpack

5
Daha fazla insan bu kısıtlamayı değiştirmesi (ve bozdukları eski API'leri düzeltmesi) için Microsoft'u zorluyor. Dosya adlarının <8>. <3> karakterleriyle sınırlandırıldığı bu kalan günlerle yaşamaya devam etmemiz için hiçbir neden yok. Hemen tamir etmeyerek daha büyük bir delik kazılıyor. Eğik çizgi yönünü oradayken sabitleyin.
cchamberlain

@cchamberlain C: / foo / bar / baz mükemmel bir şekilde geçerlidir, ancak \ foo \ bar \ baz da geçerlidir (geçerli çalışma dizini hangi mantıksal sürücüye atıfta bulunacaktır) / foo / bar / baz ile belirsizliğe neden olabilir komut satırı bayrakları.
JAB

@JAB - İleriye doğru eğik çizgi bazen işe yarıyor ama sizin de belirttiğiniz gibi güvenilir değil. cmd.exe bir şekilde tepki verirken diğerine powershell verecektir. Otomatik tamamlama molaları. Temel API bunu anlar, ancak cmd.exe her durumda bunu yapmaz ve ters eğik çizginin daha güvenli kullanımı dizelerin bazen kaçmaya ihtiyaç duymasına neden olur. Yaygın Windows yollarında bulunan boşluk ve parantez sayısıyla birlikte yeterli komut satırı ters eğik çizgi vardır.
cchamberlain

2
Çözüm değil. Teknoloji insanın hizmetçisi olmalı, insan teknolojiye hizmet etmemeli.
Daniel Hári

4

Windows'ta yönetici olarak "cmd" yi çalıştırın ve komutu çalıştırın.

"C:\Program Files\Git\mingw64\etc>"
"git config --system core.longpaths true"

veya git'in kurulu olduğu klasör için chmod yapmanız gerekir.

veya "Git \ mingw64 \ etc" yoluna giderek dosyanızı manuel olarak güncelleyin.

[http]
    sslBackend = schannel
[diff "astextplain"]
    textconv = astextplain
[filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true
[credential]
    helper = manager
**[core]
    longpaths = true**
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.