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?

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)

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.

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.

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}\.

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 .

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

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

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

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 Configuration → Szablony administracyjne → Systemu → Filesystem w gpedit.mscotwartym Włącz Win32 długie ścieżki i ustaw ją na Enabled .

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

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.

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).

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.

W maszynie z systemem Windows

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

git config --system core.longpaths true