Git ошибка проверки: невозможно создать файл

При клонировании репозитория git из Linux в систему Windows я получаю следующую ошибку при проверке фазы:

$git clone gituser @serveraddr:/ git/git_repo.git git_WA
Клонирование в "git_WA"...
gituser @serveraddr пароль:
remote: подсчет объектов: 500846, сделано.
remote: Сжатие объектов: 100% (118676/118676), сделано.
удаленный: Всего 500846 (дельта 307739), повторно использованный 483023 (дельта 291136)
Получающие объекты: 100% (500846/500846), 907,54 MiB | 9.04 MiB/s, сделано.
Разрешение дельт: 100% (307739/307739), сделано.

Ошибка: невозможно создать файл RealR **************************************** ************************************************** ************************************************** ************************************************** **************** validation.xml(Нет такого файла или каталога)
Проверка файлов: 100% (441329/441329)
Проверка файлов: 100% (441329/441329), сделано.
сделал.

Случай-2: клонирован как голый репо, извлечен из всего локального репо локально = > Те же ошибки.

Случай-3: клонировать репо в C:\прямо, проверка выполнена успешно, без ошибок.

- > Это похоже на проблему с ограничением длины имени файла/файла.

Случай-4: проверка тех же файлов из SVN-репо. Возможность проверки в любом месте без каких-либо проблем. Следовательно, никаких проблем со стороны окна. (Да, у меня есть данные в SVN и git оба, я просто перешел из SVN в GIT).

Следовательно, проблема должна быть в пределах msysgit, ограничение длины файла. Можно ли настроить длину пути в gitclient/msysgit?

Edit1: все операции выполнялись с помощью клиента TortoiseGIT v1.8.0 и git - bash: git версии 1.8.0.msysgit.0. < ш > Edit2: добавлена ​​фактическая команда, используемая при клонировании.

ОТВЕТЫ

Ответ 1

У меня возникали похожие проблемы при извлечении проекта в каталог Windows с базовым путем символов 67- (Windows) или 76- (cygwin) - при добавлении к длине пути извлеченных файлов он превышал Windows ' ограничение длины пути:

git checkout -f HEAD
error: unable to create file <194-character filepath> (No such file or directory)
fatal: cannot create directory at '<187-character directory path>': No such file
or directory

Я решил эту проблему, проверив репозиторий git на c:\git, в котором при длине 6 или 15 символов максимальная длина пути оставалась ниже предела Windows.

Ответ 2

Try:

git config --system core.longpaths true

Это позволит ему проверять файлы даже с более длинными файловыми путями. Проблема с этим будет заключаться в том, когда вы попытаетесь удалить его, поскольку Windows не позволит удалить путь дольше, чем допустимый порог. Обходной путь к этому - переименование папок в локальном репозитории, так что общая длина пути уменьшается. Например, путь, который является альфа/бета/gamma/universe.txt, может быть ограничен 1/2/3/universe.txt, так что длина находится под порогом размера файла Windows.

Ответ 3

Многие API Windows ограничены 260 символами для имени пути к файлу. Таким образом, git не может создавать файлы с именами длиной более 260 символов. Файловая система NTFS фактически поддерживает более длинные имена (32k), но нет простого способа разрешить длинные имена для программ.

Обходной путь 1: переместите проект в новое место, ближе к корню диска. Преимущество:

  • Все должно работать нормально (если нет файлов с длиной более 260)

Неудобство:

  • Вам нужно изменить расположение проекта

Обходной путь 2: создайте Junction в папке проекта из папки, которая ближе к корню диска, и выполните git клон из папки соединения. Вы можете сделать это с помощью команды mklink или Расширение командной строки.

Преимущество:

  • У вас могут быть длинные имена файлов (более 260)
  • Вы можете зарезервировать расположение проекта
  • Вы можете безопасно удалить соединение после первоначального клонирования (если вам не нужно работать с файлами, которые нарушают ограничение на 260 символов в исходном местоположении)

Неудобство:

  • Полное имя файла на узле все равно должно быть меньше 260 символов. В противном случае это решение не поможет.
  • Если вы хотите изменить файлы с длинными

Ответ 4

Единственное предложение, которое я видел, рассматривая аналогичную проблему, было:

Обход проблемы: используйте http://www.cygwin.com/

Или, по крайней мере, проверьте, работает ли проверка в git - bash session работы msysgit.

Обновление до 2015 года (2 года спустя):

Примечание: последняя версия 2.4.1 git -for-windows предлагает:

core.longpaths::

Включить поддержку длинного пути ( > 260) для встроенных команд в Git для Windows.
По умолчанию это отключено, поскольку длинные пути не поддерживаются проводником Windows, cmd.exe и цепочкой инструментов Git для Windows (msys, bash, tcl, perl...).
Только включите это, если вы знаете, что делаете, и готовы жить с несколькими причудами.

Ответ 5

Использовать Windows PowerShell. Работал для меня.