Слишком длинное имя файла в Git для Windows
Я использую Git-1.9.0-preview20140217
для Windows. Как я знаю, этот выпуск должен решить проблему со слишком длинными именами файлов. Но не для меня.
Конечно, я делаю что-то не так: я сделал git config core.longpaths true
и git add.
и затем git commit
. Все прошло гладко. Но когда я сейчас делаю состояние git status
, я получаю список файлов с Filename too long
, например:
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
Для меня это довольно просто воспроизвести: просто создайте веб-приложение Yeoman с генератором углов ("yo angular") и удалите node_modules
из файла .gitignore
. Затем повторите вышеупомянутые команды Git.
Что мне здесь не хватает?
Ответы
Ответ 1
Git имеет ограничение в 4096 символов для имени файла, за исключением Windows, когда Git компилируется с помощью msys. Он использует более старую версию Windows API и имеет ограничение в 260 символов для имени файла.
Так что, насколько я понимаю, это ограничение msys, а не Git. Вы можете прочитать подробности здесь: https://github.com/msysgit/git/pull/110
Вы можете обойти это, используя другой клиент Git в Windows или установив для core.longpaths
значение true
как описано в других ответах.
git config --system core.longpaths true
Git собран как комбинация скриптов и скомпилированного кода. С указанным выше изменением некоторые скрипты могут потерпеть неудачу. Это причина того, что core.longpaths не должен быть включен по умолчанию.
Документация Windows по адресу https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file содержит дополнительную информацию:
Начиная с Windows 10 версии 1607 ограничения MAX_PATH были удалены из общих функций файлов и каталогов Win32. Тем не менее, вы должны подписаться на новое поведение.
Раздел реестра позволяет вам включить или отключить новый длинный путь поведения. Чтобы включить поведение длинного пути, установите раздел реестра в HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Тип: REG_DWORD)
Ответ 2
Вы должны быть в состоянии выполнить команду
git config --system core.longpaths true
или добавьте его в один из файлов конфигурации Git вручную, чтобы включить эту функцию, если вы используете поддерживаемую версию Git. Похоже, может быть 1.9.0 и после.
Ответ 3
Это может помочь:
git config core.longpaths true
Основное объяснение: В этом ответе предлагается не применять такие настройки к глобальной конфигурации системы (ко всем проектам, избегая --system
или --global
). Эта команда только решает проблему, будучи специфичной для текущего проекта.
Ответ 4
Создайте.gitconfig и добавьте
[core]
longpaths = true
Вы можете создать файл в местоположении проекта (не уверен), а также в глобальном местоположении. В моем случае это C:\Users\{name}\
.
Ответ 5
Лучшее решение - включить параметр longpath из Git.
git config --system core.longpaths true
Но обходной путь, который работает, - это удалить папку node_modules из Git:
$ git rm -r --cached node_modules
$ vi .gitignore
Добавьте node_modules в новую строку внутри файла.gitignore. После этого нажмите ваши модификации:
$ git add .gitignore
$ git commit -m "node_modules removed"
$ git push
Ответ 6
Шаги, чтобы следовать:
- Запустите Git Bash от имени администратора
- Запустите команду
git config --system core.longpaths true
Подробнее о git config
читайте здесь.
Ответ 7
Чтобы быть уверенным, что он вступает в силу сразу после инициализации репозитория, но до того, как удаленная история будет извлечена или какие-либо файлы извлечены, безопаснее использовать ее следующим образом:
git clone -c core.longpaths=true <repo-url>
-c key = значение
Задайте конфигурационную переменную во вновь создаваемом репозитории; это вступает в силу сразу после инициализации репозитория, но перед извлечением удаленной истории или извлечением любых файлов. Ключ находится в том же формате, что и ожидалось git -config 1 (например, core.eol = истина). Если для одного и того же ключа задано несколько значений, каждый значение будет записано в файл конфигурации. Это делает его безопасным для Например, чтобы добавить дополнительные исправления refetch к удаленному источнику.
Дополнительная информация
Ответ 8
Вы также можете попытаться включить длинные пути к файлам.
Если вы используете Windows 10 Home Edition, вы можете изменить реестр, чтобы включить длинные пути.
Перейдите в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
в regedit
а затем установите для LongPathsEnabled
значение 1
.
Если у вас Windows 10 Pro или Enterprise, вы также можете использовать локальные групповые политики.
Перейдите в Конфигурация компьютера → Административные шаблоны → Система → Файловая система в gpedit.msc
, откройте "Включить длинные пути Win32" и установите для него значение "Включено".
Ответ 9
Выполнение git config --system core.longpaths true
мне ошибку:
"ошибка: не удалось заблокировать файл конфигурации C:\Program Files (x86)\Git\mingw32/etc/gitconfig: разрешение запрещено"
Исправлено с выполнением команды на глобальном уровне:
git config --global core.longpaths true
Ответ 10
Переместить репозиторий в корень вашего диска (временное исправление)
Вы можете попытаться временно переместить локальный репозиторий (всю папку) в корень диска или как можно ближе к корню.
Поскольку путь в корне диска меньше, это иногда устраняет проблемы.
В Windows я бы переместил это в C:\
или другой корень диска.
Ответ 11
У меня тоже была эта ошибка, но в моем случае причиной была устаревшая версия npm v1.4.28.
Обновление до npm v3 с последующим
rm -rf node_modules
npm -i
работал на меня. В выпуске npm 2697 содержатся подробные сведения о "максимально плоской" структуре папок, включенной в npm v3 (выпущена 2015-06-25).
Ответ 12
Если вы работаете с зашифрованным разделом, рассмотрите возможность перемещения папки в незашифрованный раздел, например, /tmp, запуска git pull
, а затем возврата назад.