Za długa nazwa pliku w Git dla Windows


663

Korzystam Git-1.9.0-preview20140217z systemu Windows. Jak wiem, to wydanie powinno rozwiązać problem ze zbyt długimi nazwami plików. Ale nie dla mnie.

Na pewno robię coś nie tak: zrobiłem git config core.longpaths truei git add .czym git commit. Wszystko poszło dobrze. Ale kiedy teraz robię git status, otrzymuję listę plików Filename too long, na przykład:

node_modules/grunt-contrib-imagemin/node_modules/pngquant-bin/node_modules/bin-wrapper/node_modules/download/node_modules/request/node_modules/form-data/node_modules/combined-stream/node_modules/delayed-stream/test/integration/test-handle-source-errors.js: Filename too long

Reprodukcja jest dla mnie bardzo prosta: wystarczy utworzyć aplikację internetową Yeoman za pomocą generatora Angular („yo angular”) i usunąć node_modulesz .gitignorepliku. Następnie powtórz wyżej wymienione polecenia Git.

Czego tu brakuje?


Gdzie czytasz, że ta wersja powinna naprawić długie nazwy plików?
iveqy

Oto prośba o ściągnięcie łatki: github.com/msysgit/git/pull/122
Papa Mufflon

@PapaMufflon czy możesz zmienić zaakceptowaną odpowiedź na tę z większą liczbą punktów? Bardzo mi to pomogło.
v.karbovnichy

@ v.karbovnichy proszę uważnie przeczytać moje pytanie. Uruchomiłem już komendę w najwyższej głosowanej odpowiedzi. Ale w momencie, gdy zadałem pytanie, zaakceptowana odpowiedź była prawidłowa: msys wciąż miał takie ograniczenie znaków. Teraz, gdy zniknęło ograniczenie i git config core.longpaths true działa tak, jak powinno.
Papa Mufflon

Ok, zgadzam się wtedy
v.karbovnichy

Odpowiedzi:


702

Git ma limit 4096 znaków dla nazwy pliku, z wyjątkiem Windows, gdy Git jest kompilowany z msys. Używa starszej wersji interfejsu Windows API i nazwa pliku ma limit 260 znaków.

O ile rozumiem, jest to ograniczenie msys, a nie Git. Możesz przeczytać szczegóły tutaj: https://github.com/msysgit/git/pull/110

Można obejść to za pomocą innego klienta Git na Windows lub zestaw core.longpathsdo truejak wyjaśniono w innych odpowiedzi.

git config --system core.longpaths true

Git jest budowany jako kombinacja skryptów i skompilowanego kodu. Przy powyższej zmianie niektóre skrypty mogą zawieść. To jest powód, dla którego core.longpaths nie są domyślnie włączone.

Dokumentacja systemu Windows pod adresem https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file zawiera więcej informacji:

Począwszy od systemu Windows 10, wersja 1607, ograniczenia MAX_PATH zostały usunięte ze wspólnych funkcji plików i katalogów Win32. Musisz jednak wyrazić zgodę na nowe zachowanie.

Klucz rejestru pozwala włączyć lub wyłączyć nowe zachowanie długiej ścieżki. Aby włączyć zachowanie długiej ścieżki, ustaw klucz rejestru na HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem LongPathsEnabled (Typ: REG_DWORD)


19
Ograniczenie do 260 znaków w ścieżce nie jest specyficzne dla MSYS, jest to ogólna imitacja interfejsu Windows API. Można to obejść za pomocą ścieżek Unicode, ale ma to również inne wady, dlatego core.longpathsdomyślnie nie jest włączone. Zauważ również, że Git dla Windows nie został skompilowany z MSYS. Zamiast tego jest to natywna aplikacja systemu Windows ze zredukowanym środowiskiem MSYS.
sschuberth

3
@sschuberth: Czy są jakieś wady inne niż brak zgodności z programami, które nie obsługują długich ścieżek?
JAB

3
@JAB Kolejną wadą jest to, że długie ścieżki zawsze muszą być absolutne; ścieżki względne nie są obsługiwane. Więcej informacji można znaleźć tutaj .
sschuberth

4
Lub jako szybka poprawka, po prostu wypróbuj repozytorium w C: / w systemie Windows, zmniejszając w ten sposób liczbę znaków ścieżki folderu.
Akshay Lokur

5
Do chwili obecnej problem nadal występuje. Możemy rozważyć dalszy rozwój prawdziwego systemu operacyjnego ...
Géza Török

1033

Powinieneś być w stanie uruchomić polecenie

git config --system core.longpaths true

lub dodaj go ręcznie do jednego ze swoich plików konfiguracyjnych Git, aby włączyć tę funkcję, gdy będziesz na obsługiwanej wersji Git. Wygląda może na 1.9.0 i później.


13
Ta opcja konfiguracji naprawiła dla mnie problem, nawet z msys, jak wspomniano w zaakceptowanej odpowiedzi. (W szczególności wersja 1.9.4.msysgit.2).
Alex Osborn,

5
Sourcetree działa trochę dziwnie, chyba że „upewnisz się również, że SourceTree używa Gita Systemu, a nie wbudowanego”. - Dziękuję Matejowi Drolcowi za tę radę
bstoney

38
Oto kilka podstawowych informacji o tym, dlaczego ta funkcja nie jest domyślnie włączona oraz niektóre szczegóły techniczne.
sschuberth

12
get "nie można zablokować pliku konfiguracyjnego C: \ Program Files \ Git \ mingw64 / etc / gitconfig" po uruchomieniu powyższej komendy. Ale odpowiedź @Yash zadziałała dla mnie
divideByZero

10
@divideByZero działa git bash, ponieważ administrator zapobiega temu błędowi.
Niek

204

To może pomóc:

git config core.longpaths true

Podstawowe objaśnienie: Ta odpowiedź sugeruje, aby nie stosować takiego ustawienia do konfiguracji globalnego systemu (do wszystkich projektów, aby unikać konfiguracji --systemlub --globaloznaczać). To polecenie rozwiązuje problem tylko dlatego, że jest specyficzne dla bieżącego projektu.


13
Ludzie tutaj zauważyli, że to ustawienie może wprowadzić pewne nieprzewidziane zachowanie, więc wydaje się, że lepiej jest użyć powyższego polecenia jako ustawienia lokalnego w projektach, które tego wymagają, zamiast dołączać, --systemco będzie stosować je do wszystkich projektów
Grant Humphries,

4
hej, to tylko kopia innej bardzo pozytywnej odpowiedzi. może przynajmniej wyjaśnić, dlaczego wolisz usunąć opcję --system ..
Félix Gagnon-Grenier,

78

Utwórz .gitconfig i dodaj

[core]
longpaths = true

Możesz utworzyć plik w lokalizacji projektu (nie jestem pewien), a także w lokalizacji globalnej. W moim przypadku jest to lokalizacja C:\Users\{name}\.


10
Możesz to również zrobić za pomocą następującego polecenia:git config --global core.longpaths true
Curly

git config --global core.longpaths true działało dla mnie dzięki
Rama Krshna Ila

1
Przy użyciu Visual Studio powyższe rozwiązania git bash nie działały dla mnie, ale znalezienie pliku .git / config dla projektu i edycja jak pokazano powyżej. Dzięki, yash.
andrew pate

to zadziałało dla mnie, zlokalizowałem ten plik i zmodyfikowałem go ręcznie
Patlatus

1
Wyżej wymienione i zweryfikowane odpowiedzi są poprawne, ale przy uprawnieniach do pliku aktualizacja plików przy użyciu tych poleceń może być niemożliwa. To podejście jest naprawdę łatwe, ponieważ jest to podejście ręczne i zadziałało dla mnie naprawdę dobrze. Możesz łatwo znaleźć .gitconfigplik w następującej ścieżce C:\Users\{username}i po prostu go edytować.
Kavindu Narathota

53

Kroki do naśladowania:

  1. Uruchom Git Bash jako administrator
  2. Uruchom następujące polecenie:
git config --system core.longpaths true

Uwaga : jeśli krok 2 nie działa lub występuje błąd, możesz także spróbować uruchomić to polecenie:

git config --global core.longpaths true

Przeczytaj więcej o git config tutaj .


35

Lepszym rozwiązaniem jest włączenie parametru longpath z Git.

git config --system core.longpaths true

Ale obejściem, które działa, jest usunięcie folderu node_modules z Git:

$ git rm -r --cached node_modules
$ vi .gitignore

Dodaj moduły_węzła w nowym wierszu w pliku .gitignore. Po wykonaniu tej czynności wciśnij swoje modyfikacje:

$ git add .gitignore
$ git commit -m "node_modules removed"
$ git push

3
Jest dobry powód, aby zachować folder node_modules w git: Jeśli chcesz, aby twoje oprogramowanie zachowywało się tak samo po roku modułów potencjalnie znikających z npm.
cfstras

@ cfstras, jeśli niektóre biblioteki zawierają luki i nie aktualizujesz ich okresowo, na pewno będziesz mieć problemy z bezpieczeństwem.
Janderson Silva

1
Oczywiście musisz zaktualizować swoje zależności. Ale tylko wtedy , gdy chcesz i gdyby coś się
zepsuło

Jest prawdziwy. Zmienię moją odpowiedź. Dziękuję za twój komentarz.
Janderson Silva

1
Nie ma potrzeby zatwierdzania node_modules: packages.lockplik jest tutaj, aby upewnić się, że zainstalowana wersja npm installbędzie zawsze taka sama, dopóki nie dokonasznpm update
Pierre-Olivier Vares

32

Aby mieć całkowitą pewność, że zadziała natychmiast po zainicjowaniu repozytorium, ale przed pobraniem historii zdalnej lub wyewidencjonowaniem jakichkolwiek plików, bezpieczniej jest użyć jej w ten sposób:

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

-c klucz = wartość

Ustaw zmienną konfiguracyjną w nowo utworzonym repozytorium; działa to natychmiast po zainicjowaniu repozytorium, ale przed pobraniem historii zdalnej lub wyewidencjonowaniem plików. Klucz ma taki sam format, jak oczekiwany przez git-config 1 (np. Core.eol = true). Jeśli podano wiele wartości dla tego samego klucza, każda wartość zostanie zapisana w pliku konfiguracyjnym. Dzięki temu można na przykład bezpiecznie dodawać dodatkowe pliki referencyjne pobierania do pilota źródłowego.

Więcej informacji


24

Wykonanie git config --system core.longpaths truezwróciło mi błąd:

„błąd: nie można zablokować pliku konfiguracyjnego C: \ Program Files (x86) \ Git \ mingw32 / etc / gitconfig: Odmowa dostępu”

Naprawiono podczas wykonywania polecenia na poziomie globalnym:

git config --global core.longpaths true

Ustawienia globalne wpływają tylko na bieżącego użytkownika, podczas gdy ustawienia systemowe wpływają na wszystkich użytkowników komputera. Jeśli jest to Twoja stacja robocza, są one faktycznie takie same, ponieważ możesz korzystać tylko z jednego użytkownika.
ręcznik

4
Jeśli jesteś aplikacją z linii poleceń Ran jako Administrator, pierwsze polecenie będzie działać!
Sachith Dickwella

12

Możesz także spróbować włączyć długie ścieżki plików.

Jeśli korzystasz z systemu Windows 10 Home Edition, możesz zmienić rejestr, aby umożliwić długie ścieżki.

Idź do HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemw regedit, a następnie ustawić LongPathsEnabledsię 1.

Jeśli masz system Windows 10 Pro lub Enterprise, możesz także użyć lokalnych zasad grupy.

Idź do Computer ConfigurationSzablony administracyjneSystemuFilesystem w gpedit.mscotwartym Włącz Win32 długie ścieżki i ustaw ją na Enabled .


5
Uważam, że należy to zrobić w połączeniu z konfiguracją git i warto zauważyć, że nie działa z Eksploratorem Windows z powodów wymienionych tutaj .
Neo

11
git config --global core.longpaths true

Powyższe polecenie działało dla mnie. Użycie „--system” dało mi błąd niezablokowanego pliku konfiguracyjnego


2
dla użytkowników Github Desktop jest to jedyny działający, ponieważ Github Desktop używa własnej konfiguracji Git.
Csaba

4

Przenieś repozytorium do katalogu głównego dysku (poprawka tymczasowa)

Możesz spróbować tymczasowo przenieść lokalne repozytorium (cały folder) do katalogu głównego dysku lub jak najbliżej katalogu głównego.

Ponieważ ścieżka jest mniejsza w katalogu głównym dysku, czasami rozwiązuje problemy.

W systemie Windows przeniósłbym to do C:\katalogu głównego lub innego dysku.


2
To jedyna rzecz, która rozwiązała mój problem. Było tak, że miałem zbyt wiele folderów na ścieżce.
J Brune,

2

Miałem również ten błąd, ale w moim przypadku przyczyną było użycie nieaktualnej wersji npm, v1.4.28.

Aktualizacja do npm v3, a następnie

rm -rf node_modules
npm -i

pracował dla mnie. Wydanie 2697 npm zawiera szczegółowe informacje na temat struktury folderów „maksymalnie płaskich” zawartych w npm v3 (wydany 25.6.2015).


1

Jeśli pracujesz z zaszyfrowaną partycją, rozważ przeniesienie folderu na niezaszyfrowaną partycję, na przykład a / tmp , uruchomienie git pull, a następnie powrót.


0

W maszynie z systemem Windows

Uruchom wiersz polecenia jako administrator, a następnie uruchom poniżej polecenia

git config --system core.longpaths true

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.