J'utilise Git-1.9.0-preview20140217pour Windows. Comme je le sais, cette version devrait résoudre le problème avec des noms de fichiers trop longs. Mais pas pour moi.

Certes , je fais quelque chose de mal: je l' ai fait git config core.longpaths trueet git add .puis git commit. Tout s'est bien passé. Mais quand je fais maintenant un git status, j'obtiens une liste de fichiers avec Filename too long, par exemple:

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

C'est assez simple à reproduire pour moi: il suffit de créer une application web Yeoman avec le générateur angulaire ("yo angular") et de le supprimer node_modulesdu .gitignorefichier. Répétez ensuite les commandes Git susmentionnées.

Qu'est-ce que j'oublie ici?

Git a une limite de 4096 caractères pour un nom de fichier, sauf sous Windows lorsque Git est compilé avec msys. Il utilise une ancienne version de l'API Windows et il y a une limite de 260 caractères pour un nom de fichier.

Donc, pour autant que je comprends cela, c'est une limitation de msys et non de Git. Vous pouvez lire les détails ici: https://github.com/msysgit/git/pull/110

Vous pouvez contourner cela en utilisant un autre client Git sous Windows ou définissez- core.longpathsle truecomme expliqué dans d'autres réponses.

git config --system core.longpaths true

Git est construit comme une combinaison de scripts et de code compilé. Avec la modification ci-dessus, certains scripts peuvent échouer. C'est la raison pour laquelle core.longpaths ne doit pas être activé par défaut.

La documentation Windows sur https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file contient quelques informations supplémentaires:

À partir de Windows 10, version 1607, les limitations MAX_PATH ont été supprimées des fonctions de fichier et de répertoire Win32 courantes. Cependant, vous devez accepter le nouveau comportement.

Une clé de registre vous permet d'activer ou de désactiver le nouveau comportement de chemin long. Pour activer le comportement de chemin long, définissez la clé de Registre dans HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem LongPathsEnabled (Type: REG_DWORD)

Vous devriez pouvoir exécuter la commande

git config --system core.longpaths true

ou ajoutez-le manuellement à l'un de vos fichiers de configuration Git pour activer cette fonctionnalité, une fois que vous êtes sur une version prise en charge de Git. Il ressemble peut-être à la version 1.9.0 et aux versions ultérieures.

Cela pourrait aider:

git config core.longpaths true

Explication de base: Cette réponse suggère de ne pas appliquer un tel paramètre aux configurations du système global (à tous les projets, afin d'éviter --systemou d' --globalétiqueter). Cette commande ne résout le problème qu'en étant spécifique au projet en cours.

Créez .gitconfig et ajoutez

[core]
longpaths = true

Vous pouvez créer le fichier dans un emplacement de projet (pas sûr) et également dans l'emplacement global. Dans mon cas, l'emplacement est C:\Users\{name}\.

Étapes à suivre:

1. Exécutez Git Bash en tant qu'administrateur
2. Exécutez la commande suivante:

git config --system core.longpaths true

Remarque : si l'étape 2 ne fonctionne pas ou donne une erreur, vous pouvez également essayer d'exécuter cette commande:

git config --global core.longpaths true

En savoir plus git config ici .

La meilleure solution est d'activer le paramètre longpath de Git.

git config --system core.longpaths true

Mais une solution de contournement qui fonctionne est de supprimer le dossier node_modules de Git:

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

Ajoutez node_modules dans une nouvelle ligne à l'intérieur du fichier .gitignore. Après cela, poussez vos modifications:

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

Pour être entièrement sûr qu'il prend effet immédiatement après l'initialisation du référentiel, mais avant que l'historique distant ne soit récupéré ou que tous les fichiers soient extraits, il est plus sûr de l'utiliser de cette façon:

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

-c clé = valeur

Définissez une variable de configuration dans le référentiel nouvellement créé; cela prend effet immédiatement après l'initialisation du référentiel, mais avant la récupération de l'historique distant ou l'extraction de tout fichier. La clé est dans le même format que prévu par git-config 1 (par exemple, core.eol = true). Si plusieurs valeurs sont données pour la même clé, chaque valeur sera écrite dans le fichier de configuration. Cela permet, par exemple, d'ajouter en toute sécurité des références de récupération supplémentaires à la télécommande d'origine.

Plus d'informations

L'exécution git config --system core.longpaths truem'a renvoyé une erreur:

"erreur: impossible de verrouiller le fichier de configuration C: \ Program Files (x86) \ Git \ mingw32 / etc / gitconfig: autorisation refusée"

Correction de l'exécution de la commande au niveau global:

git config --global core.longpaths true

Vous pouvez également essayer d'activer les longs chemins d'accès aux fichiers.

Si vous exécutez Windows 10 Home Edition, vous pouvez modifier votre registre pour activer les longs chemins.

Aller à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemen regeditpuis mis LongPathsEnabledà 1.

Si vous avez Windows 10 Pro ou Enterprise, vous pouvez également utiliser des stratégies de groupe locales.

Aller à Configuration ordinateur → Modèles d' administration → Système → Système de fichiers à gpedit.msc, ouvert Activer longs chemins Win32 et réglez -le sur Activé .

git config --global core.longpaths true

La commande ci-dessus a fonctionné pour moi. L'utilisation de '--system' m'a donné une erreur de fichier de configuration non verrouillé

Déplacer le référentiel vers la racine de votre lecteur (correction temporaire)

Vous pouvez essayer de déplacer temporairement le référentiel local (le dossier entier) vers la racine de votre lecteur ou aussi près de la racine que possible.

Étant donné que le chemin est plus petit à la racine du lecteur, il résout parfois les problèmes.

Sous Windows, je déplacerais ceci vers C:\la racine d'un autre lecteur.

J'ai également eu cette erreur, mais dans mon cas, la cause était une version obsolète de npm, v1.4.28.

Mise à jour vers npm v3 suivie de

rm -rf node_modules
npm -i

travaillé pour moi. Le problème npm 2697 contient des détails sur la structure de dossiers "au maximum plat" incluse dans npm v3 (publiée le 2015-06-25).

Si vous travaillez avec votre partition chiffrée, envisagez de déplacer le dossier vers une partition non chiffrée, par exemple a / tmp , en cours d'exécution git pull, puis en revenant en arrière.

Dans une machine Windows

Exécutez l'invite de commandes en tant qu'administrateur, puis exécutez la commande ci-dessous

git config --system core.longpaths true