665

Sto usando Git-1.9.0-preview20140217per Windows. Come so, questa versione dovrebbe risolvere il problema con nomi di file troppo lunghi. Ma non per me.

Sicuramente sto facendo qualcosa di sbagliato: ho fatto git config core.longpaths truee git add ., quindi git commit. Tutto andò bene. Ma quando ora faccio un git status, ottengo un elenco di file con Filename too long, ad esempio:

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

È abbastanza semplice riprodurlo per me: basta creare un'applicazione web Yeoman con il generatore angolare ("yo angular") e rimuoverlo node_modulesdal .gitignorefile. Quindi ripetere i suddetti comandi Git.

Cosa mi sto perdendo qui?

windows git

— Papa Mufflon
fonte

Dove leggi che quella versione dovrebbe correggere i nomi di file lunghi?

— iveqy

Ecco la richiesta pull per la patch: github.com/msysgit/git/pull/122

— Papa Mufflon

@PapaMufflon puoi cambiare la risposta accettata a quella con più punteggio? Mi ha solo aiutato molto.

— v.karbovnichy,

@ v.karbovnichy, leggi attentamente la mia domanda. Ho già eseguito il comando nella risposta più votata. Ma quando ho posto la domanda, la risposta accettata era corretta: msys aveva ancora questa limitazione di carattere. Ora questa limitazione è sparita e git config core.longpaths true funziona come dovrebbe.

— Papa Mufflon,

Ok, sono d'accordo allora

— v.karbovnichy il

707

Git ha un limite di 4096 caratteri per un nome file, tranne su Windows quando Git è compilato con msys. Utilizza una versione precedente dell'API di Windows e esiste un limite di 260 caratteri per un nome file.

Per quanto ho capito, è una limitazione di msys e non di Git. Puoi leggere i dettagli qui: https://github.com/msysgit/git/pull/110

È possibile aggirare questo utilizzando un altro client Git su Windows o set core.longpathsper truecome spiegato in altre risposte.

git config --system core.longpaths true

Git è compilato come una combinazione di script e codice compilato. Con la modifica precedente alcuni degli script potrebbero non riuscire. Questo è il motivo per cui core.longpaths non deve essere abilitato per impostazione predefinita.

La documentazione di Windows su https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file contiene alcune ulteriori informazioni:

A partire da Windows 10, versione 1607, le limitazioni MAX_PATH sono state rimosse dalle comuni funzioni di file e directory di Win32. Tuttavia, è necessario attivare il nuovo comportamento.

Una chiave di registro consente di abilitare o disabilitare il nuovo comportamento del percorso lungo. Per abilitare il comportamento del percorso lungo, impostare la chiave del Registro di sistema in HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem LongPathsEnabled (Tipo: REG_DWORD)

— iveqy
fonte

19

La limitazione a 260 caratteri in un percorso non è specifica per MSYS, è un'imitazione generale dell'API di Windows. Questo può essere risolto utilizzando i percorsi Unicode, ma presenta altri svantaggi, motivo per cui core.longpathsnon è abilitato per impostazione predefinita. Si noti inoltre che Git per Windows non è stato compilato con MSYS. Invece, è un'applicazione Windows nativa che viene fornita con un ambiente MSYS ridotto.

— sschuberth,

3

@sschuberth: esistono altri svantaggi oltre alla mancanza di compatibilità con i programmi che non supportano percorsi lunghi?

— JAB,

3

@JAB Un altro svantaggio è che i percorsi lunghi devono essere sempre assoluti; i percorsi relativi non sono supportati. Per ulteriori dettagli, consultare qui .

— sschuberth,

4

O come soluzione rapida, prova a controllare il tuo repository in C: / su Windows, riducendo così il numero di caratteri del percorso della cartella.

— Akshay Lokur,

5

Cordiali saluti, ormai il problema persiste ancora. Potremmo voler considerare il continuo sviluppo su un vero sistema operativo ...

— Géza Török

1035

Dovresti essere in grado di eseguire il comando

git config --system core.longpaths true

o aggiungilo manualmente a uno dei tuoi file di configurazione di Git per attivare questa funzionalità, una volta che sei su una versione supportata di Git. Sembra forse 1.9.0 e successivi.

— sparkym3
fonte

13

Questa opzione di configurazione ha risolto il problema per me, anche con msys come indicato nella risposta accettata. (In particolare, versione 1.9.4.msysgit.2).

— Alex Osborn,

5

Sourcetree agisce in modo un po 'strano a meno che tu non "assicuri anche che SourceTree stia usando Git del sistema e non quello incorporato". - Grazie a Matej Drolc per quel consiglio

— bstoney

38

Ecco alcune informazioni di base sul perché questo non è abilitato per impostazione predefinita e alcuni dettagli tecnici.

— sschuberth,

12

get "impossibile bloccare il file di configurazione C: \ Programmi \ Git \ mingw64 / etc / gitconfig" dopo aver eseguito il comando sopra. Ma la risposta di @Yash ha funzionato per me

— divideByZero

10

@divideByZero esegue git bash come amministratore impedisce quell'errore.

— Niek,

205

Questo potrebbe aiutare:

git config core.longpaths true

Spiegazione di base: questa risposta suggerisce di non applicare tale impostazione al sistema globale (a tutti i progetti, evitando --systemo --globaltag) le configurazioni. Questo comando risolve il problema solo specificando il progetto corrente.

— Sagiruddin Mondal
fonte

13

La gente qui ha notato che questa impostazione può introdurre un comportamento imprevedibile, quindi sembra che sia preferibile usare il comando sopra come impostazione locale su progetti in cui ciò lo richiede piuttosto che aggiungere --systemche lo applicherà a tutti i progetti

— Grant Humphries

4

ehi, questa è solo una copypasta dell'altra risposta altamente votata. potrebbe almeno spiegare perché preferisci rimuovere l'opzione --system ..

— Félix Gagnon-Grenier,

79

Crea .gitconfig e aggiungi

[core]
longpaths = true

È possibile creare il file in un percorso di progetto (non sicuro) e anche in un percorso globale. Nel mio caso la posizione è C:\Users\{name}\.

— Yash
fonte

10

Puoi anche farlo con il seguente comando:git config --global core.longpaths true

— Curly

git config --global core.longpaths true ha funzionato per me grazie

— Rama Krshna Ila

1

Usando Visual Studio le soluzioni git bash sopra non funzionavano per me, ma trovare il file .git / config per il progetto e modificarlo come mostrato sopra. Grazie yash.

— andrew pate

questo ha funzionato per me, ho trovato quel file e l'ho modificato manualmente

— Patlatus,

1

Le risposte sopra menzionate e verificate sono corrette ma con le autorizzazioni concesse al file, potrebbe non essere possibile aggiornare il file con questi comandi. Questo approccio è davvero semplice perché questo è l'approccio manuale e ha funzionato davvero bene per me. Puoi facilmente trovare il .gitconfigfile nel seguente percorso C:\Users\{username}e semplicemente modificarlo.

— Kavindu Narathota,

53

Passaggi da seguire:

Esegui Git Bash come amministratore
Esegui il seguente comando:

git config --system core.longpaths true

Nota : se il passaggio 2 non funziona o genera errori, puoi anche provare a eseguire questo comando:

git config --global core.longpaths true

Leggi di più git config qui .

— Saikat
fonte

35

La soluzione migliore è abilitare il parametro longpath di Git.

git config --system core.longpaths true

Ma una soluzione alternativa che funziona è rimuovere la cartella node_modules da Git:

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

Aggiungi node_modules in una nuova riga all'interno del file .gitignore. Dopo aver fatto ciò, spingi le tue modifiche:

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

— Janderson Silva
fonte

3

C'è una buona ragione per tenere la cartella node_modules sotto controllo in git: se vuoi che il tuo software si comporti allo stesso modo dopo un anno di moduli potenzialmente spariti da npm.

— cfstras,

@cfstras se alcune librerie hanno una vulnerabilità e non si aggiorna periodicamente, sicuramente avrai problemi di sicurezza.

— Janderson Silva,

1

Ovviamente devi aggiornare le tue dipendenze. Ma solo quando si desidera, e se qualcosa dovesse rompere, si vorrebbe il backup in git ...

— cfstras

È vero. Modificherò la mia risposta. Grazie per il tuo commento.

— Janderson Silva,

1

Non è necessario eseguire il commit node_modules: il packages.lockfile è qui per garantire che la versione installata npm installsarà sempre la stessa, fino a quando non si effettua unanpm update

— Pierre-Olivier Vares,

32

Per essere completamente sicuri che abbia effetto immediatamente dopo l'inizializzazione del repository, ma prima che venga recuperata la cronologia remota o che siano stati estratti eventuali file, è più sicuro utilizzarlo in questo modo:

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

-c chiave = valore

Imposta una variabile di configurazione nel repository appena creato; questo ha effetto immediatamente dopo l'inizializzazione del repository, ma prima che venga recuperata la cronologia remota o che siano stati estratti eventuali file. La chiave è nello stesso formato previsto da git-config 1 (ad es. Core.eol = true). Se vengono forniti più valori per la stessa chiave, ogni valore verrà scritto nel file di configurazione. Ciò rende sicuro, ad esempio, aggiungere ulteriori refspec di recupero al telecomando di origine.

Ulteriori informazioni

— Orologiaio
fonte

24

L'esecuzione mi ha git config --system core.longpaths truelanciato un errore:

"errore: impossibile bloccare il file di configurazione C: \ Programmi (x86) \ Git \ mingw32 / etc / gitconfig: autorizzazione negata"

Risolto con l'esecuzione del comando a livello globale:

git config --global core.longpaths true

— Arpit Aggarwal
fonte

Le impostazioni globali riguardano solo l'utente corrente, mentre le impostazioni di sistema riguardano tutti gli utenti sulla macchina. Se questa è la tua postazione di lavoro sono effettivamente gli stessi che puoi usare solo un utente.

— asciugamano

4

Se l'applicazione della riga di comando è stata eseguita come amministratore, il primo comando funzionerebbe!

— Sachith Dickwella,

12

Puoi anche provare ad abilitare percorsi di file lunghi.

Se esegui Windows 10 Home Edition puoi modificare il registro per abilitare percorsi lunghi.

Vai a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemin regedite quindi imposta LongPathsEnabledsu 1.

Se disponi di Windows 10 Pro o Enterprise, puoi utilizzare anche Criteri di gruppo locali.

Vai a Configurazione computer → Modelli amministrativi → Sistema → File system in gpedit.msc, apri Abilita percorsi lunghi Win32 e impostalo su Abilitato .

— Julian Veerkamp
fonte

5

Credo che questo debba essere fatto in combinazione con git config, e vale la pena notare che non funziona con Windows Explorer per i motivi menzionati qui .

— Neo

11

git config --global core.longpaths true

Il comando sopra ha funzionato per me. Usando '--system' mi ha dato il file di configurazione non bloccato errore

— amalik2205
fonte

2

per gli utenti di Github Desktop, questo è l'unico che funziona perché Github Desktop utilizza la propria configurazione Git.

— Csaba,

4

Sposta il repository nella directory principale dell'unità (correzione temporanea)

Puoi provare a spostare temporaneamente il repository locale (l'intera cartella) nella radice dell'unità o il più vicino possibile alla radice.

Poiché il percorso è più piccolo alla radice dell'unità, a volte risolve i problemi.

Su Windows, sposterei questo nella C:\radice di un'altra unità.

— Dheeraj Bhaskar
fonte

2

Questa è l'unica cosa che ha risolto il mio problema. Era che avevo troppe cartelle nel percorso.

— J Brune,

2

Ho avuto anche questo errore, ma nel mio caso la causa stava usando una versione obsoleta di npm, v1.4.28.

Aggiornamento a npm v3 seguito da

rm -rf node_modules
npm -i

ha funzionato per me. Il numero 2697 di npm contiene dettagli sulla struttura di cartelle "massimamente piatta" inclusa in npm v3 (rilasciato il 25/06/2015).

— James Green
fonte

1

Se stai lavorando con la tua partizione crittografata, considera di spostare la cartella in una partizione non crittografata, ad esempio un / tmp , in esecuzione git pulle quindi tornare indietro.

— augustowebd
fonte

0

In una macchina Windows

Esegui il prompt dei comandi come amministratore, quindi esegui sotto il comando

git config --system core.longpaths true

— Kartick Shaw
fonte

Nome file troppo lungo in Git per Windows

Passaggi da seguire:

Sposta il repository nella directory principale dell'unità (correzione temporanea)

In una macchina Windows