git pull przerwał działanie z błędną nazwą pliku za długą

114

Używam systemu Windows jako systemu operacyjnego i pracuję nad projektem z przyjacielem, który używa komputera Mac. Sprawdził kod na naszym Githubie.

Próbowałem wyciągnąć wszystko, co zrobił, i zakończyło się z błędem „zbyt długa nazwa pliku” w kodzie strony trzeciej.

Co mogę zrobić?

git

— Dave Martin
źródło

Ten problem ma dwa zasadniczo różne przypadki, w zależności od twojej operacji. Jeśli repozytorium już istnieje, możesz edytować jego konfigurację. A jeśli nie? W przypadku klonowania / pobierania z tworzeniem nowego katalogu pomoże tylko odpowiedź @AlexRosenfeld.

— Gangnus,

200

Często zadawane pytania dotyczące msysgit na Git nie mogą utworzyć katalogu z długą ścieżką, który nie wydaje się aktualny, ponieważ nadal zawiera linki do starego biletu msysgit # 110 . Jednak zgodnie z późniejszym biletem # 122 problem został naprawiony w msysgit 1.9, a zatem:

Zaktualizuj do msysgit 1.9 (lub nowszej)
Uruchom Git Bash
Przejdź do repozytorium Git, które „cierpi” na problem z długimi ścieżkami
Włącz obsługę długich ścieżek z git config core.longpaths true

Jak dotąd bardzo mi się to udało.

Zwróć uwagę na ważną uwagę w komentarzu do biletu # 122

nie wracaj tutaj i nie narzekaj, że psuje Eksploratora Windows, cmd.exe, bash lub jakiekolwiek narzędzia, których używasz.

— mloskot
źródło

Jest kilka aktualizacji, wygląda na to, że jest jakiś dodatkowy skrypt, który musisz uruchomić po zainstalowaniu mysysgit github.com/msysgit/git/pull/122#issuecomment-43653756

— Adam Grant

18

To, co faktycznie zadziałało, to: git config --global core.longpaths true

— Anton Andreev

@AntonAndreev Tak, jeśli chcesz ustawić to w zakresie globalnym, to jest OK. Zakres lokalny na repozytorium jest również całkowicie poprawny.

— mloskot

Nie zadziałało to dla mnie bez ustawienia go na poziomie globalnym.

— Anton Andreev

1

W ten sposób nie będzie działać w przypadku klonowania / pobierania przy tworzeniu nowego katalogu. Pomoże tylko odpowiedź @AlexRosenfeld.

— Gangnus,

69

Rozwiązanie 1 - ustaw globalną konfigurację, uruchamiając to polecenie:

git config --system core.longpaths true

Rozwiązanie2 - lub możesz edytować bezpośrednio swój określony plik konfiguracyjny git, jak poniżej:

YourRepoFolder -> .git -> config:

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

Rozwiązanie 3 - przy klonowaniu nowego repozytorium: tutaj .

— Daniel Hári
źródło

1

W ten sposób nie będzie działać w przypadku klonowania / pobierania przy tworzeniu nowego katalogu. Pomoże tylko odpowiedź @AlexRosenfeld.

— Gangnus,

Zaktualizowałem odpowiedź tym, aby mieć w jednym miejscu, dzięki.

— Daniel Hári

26

Kilka lat później, ale chciałbym dodać, że jeśli chcesz to zrobić za jednym zamachem (tak jak ja), możesz ustawić ustawienia konfiguracyjne podczas polecenia clone. Spróbuj tego:

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

— xandermonkey
źródło

1

Zdrowie przyjacielu! Działało to świetnie podczas klonowania nowego katalogu z github.

— Jay Killeen

Nie ma problemu, cieszę się, że pomogło!

— xandermonkey

1

Tak! Ten, a do klonowania - działa tylko ten!

— Gangnus,

To nie działa, moje klonowanie nadal jest przerywane. Używam git version 1.8.4.msysgit.0, jakikolwiek pomysł?

— Proste rozwiązanie

Wygląda na to, że jest to przestarzałe . Może spróbuj użyć git-scm? Jaki błąd otrzymujesz?

— xandermonkey

12

Otwórz plik your.gitconfig, aby dodać właściwość longpaths. Będzie więc wyglądać następująco:

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

— Pete
źródło

1

W ten sposób nie będzie działać w przypadku klonowania / pobierania przy tworzeniu nowego katalogu. Pomoże tylko odpowiedź @AlexRosenfeld.

— Gangnus,

6

Jako ktoś, kto nieustannie napotykał ten problem z repozytoriami java w systemie Windows, najlepszym rozwiązaniem jest zainstalowanie Cygwin ( https://www.cygwin.com/ ) i użycie jego instalacji git w ramach wszystkich> devel> git.

Powodem, dla którego jest to najlepsze rozwiązanie, z jakim się spotkałem, jest to, że Cygwin zarządza długimi nazwami ścieżek, więc inne dostarczone polecenia przynoszą korzyści. Np. Znajdź, cp i rm. Zaufaj mi, prawdziwy problem zaczyna się, gdy musisz usunąć nazwy ścieżek, które są zbyt długie w systemie Windows.

— Tristan
źródło

4

Staraj się trzymać pliki bliżej katalogu głównego systemu plików. Więcej szczegółów: z przyczyn technicznych Git dla Windows nie może tworzyć plików ani katalogów, gdy ścieżka bezwzględna jest dłuższa niż 260 znaków .

— Michael Ver
źródło

Wygląda na to, że może przejść tylko do 130 [może Windows używa domyślnie dwubajtowych znaków Unicode] [?]

— rogerdpack

5

Więcej osób powinno naciskać na firmę Microsoft, aby zmienił to ograniczenie (i naprawił starsze interfejsy API, które psują). Nie ma powodu, dla którego mielibyśmy nadal żyć z resztkami dni, kiedy nazwy plików były ograniczone do <8>. <3> znaków. Nie naprawiając go od razu, wykopuje się większy otwór. Ustal kierunek cięcia, gdy jesteś na tym.

— cchamberlain

@cchamberlain C: / foo / bar / baz jest całkowicie poprawne, chociaż \ foo \ bar \ baz jest również poprawne (będzie odnosić się do dowolnego dysku logicznego, na którym znajduje się bieżący katalog roboczy) / foo / bar / baz może powodować niejednoznaczność z flagi wiersza poleceń.

— JAB,

@JAB - To prawda, że ukośnik w przód czasami działa, ale jak zauważyłeś, nie jest wiarygodny. cmd.exe zareaguje w jeden sposób, a powershell w inny. Przerwy w autouzupełnianiu. Bazowy interfejs API to rozumie, ale cmd.exe nie we wszystkich przypadkach, a bezpieczniejsze użycie odwrotnego ukośnika powoduje, że ciągi czasami wymagają zmiany znaczenia. Jest już wystarczająco dużo śmieci z odwrotnym ukośnikiem wiersza poleceń z liczbą spacji i nawiasów, które istnieją w typowych ścieżkach systemu Windows.

— cchamberlain

2

To nie jest rozwiązanie. Technologia powinna służyć człowiekowi, a nie człowiek powinien służyć technologii.

— Daniel Hári

4

W systemie Windows uruchom „cmd” jako administrator i wykonaj polecenie.

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

lub musisz wykonać chmod dla folderu, w którym jest zainstalowany git.

lub ręcznie zaktualizuj plik, przechodząc do ścieżki „Git \ mingw64 \ etc”

[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**

— Kumar Abhishek
źródło