2013-02-11 3 views
11

Хотя клонировать репозиторий из Linux в системе Windows, я получаю следующее сообщение об ошибке в проверке фазы:мерзавец ошибка фотографии: не удалось создать файл

$ git clone [email protected]:/git/git_repo.git git_WA
Cloning into 'git_WA'...
[email protected]'s password:
remote: Counting objects: 500846, done.
remote: Compressing objects: 100% (118676/118676), done.
remote: Total 500846 (delta 307739), reused 483023 (delta 291136)
Receiving objects: 100% (500846/500846), 907.54 MiB | 9.04 MiB/s, done.
Resolving deltas: 100% (307739/307739), done.

error: unable to create file RealR**************************************************************************************************************************************************************************************************************validation.xml (No such file or directory)
Checking out files: 100% (441329/441329)
Checking out files: 100% (441329/441329), done.
done.

Case-2: Клонирование, как голые репо, извлечение всех из голого репо локально => Такая же ошибка.

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

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

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

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

Edit1: Все операции пытались с TortoiseGit клиента v1.8.0 и ГИТ-Баш: мерзавца версии 1.8.0.msysgit.0.
Edit2: Добавлена ​​фактическая команда, используемая при клонировании.

ответ

2

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

Workaround: use http://www.cygwin.com/

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


мая Update 2015 (2 года спустя):

Замечание: при latest 2.4.1 git-for-windows proposes:

core.longpaths:: 

Enable long path (> 260) support for builtin commands in Git for Windows.
This is disabled by default, as long paths are not supported by Windows Explorer, cmd.exe and the Git for Windows tool chain (msys, bash, tcl, perl...).
Only enable this if you know what you're doing and are prepared to live with a few quirks.

+0

Я пробовал все эти операции с помощью git-bash: git version 1.8.0.msysgit.0 и TortoiseGIT client v1.8.0, который внутренне использует тот же самый msysgit. Отредактировал вопрос с той же информацией. – rohit

+0

@rohit cygwin предложит совершенно другую среду, которая должна поддерживать более длинную длину пути (http://stackoverflow.com/questions/3144082/difference-between-msysgit-and-cygwin-git/3144417#3144417). Гит-клиент на базе Windows не может получить путь к ограничению длины пути Windows. – VonC

+0

Я попытался с _git-bash_, который всегда запускается с _cygwin_. Кроме того, у меня есть независимая _cygwin_, установленная в моей системе. Итак, попробовал checkout с _cygwin_, но столкнулся с той же проблемой. Я что-то делаю неправильно. – rohit

11

я испытал подобные проблемы, проверяя проект в каталог 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 

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

+0

+1 У той же проблемы - отличный ответ –

+0

Это было для меня проблемой. Хорошим показателем для этого является проблема в том, что один файл с особенно длинным именем не удастся после успешной работы других файлов. – Shadetheartist

+0

Большое спасибо! –

5

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

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

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

Неудобство:

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

Обход 2: создайте Junction в папку проекта из папки, которая ближе к di sk root и сделать git clone из папки соединения. Вы можете сделать это с помощью команды mklink или Link Shell Extension.

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

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

Неудобство:

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

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

2

Try:

git config --system core.longpaths true 

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

+0

запустить это из Git Bash с повышенными привилегиями (запустить как admin) – dashesy

Смежные вопросы