Что происходит, когда я клонирую репозиторий с символическими ссылками в Windows?

Ответ 1

Так как версия 1.5.3 собственного Git клиента git clone и git init проверит целевую файловую систему для symlink поддерживайте и настраивайте конфигурацию локального репозитория для core.symlinks соответственно, т.е. false для FAT или NTFS. Это делает символические ссылки, созданные и переданные, например. под Linux отображаются как текстовые файлы, содержащие текст ссылки под Windows (см. git конфигурационная документация по core.symlinks для деталей).

Поскольку git для Windows версии 2.10.2 установщик имеет явная опция для поддержки символической ссылки.

В старых версиях Git для Windows вы можете вручную установить core.symlinks на true, который включил Git для создания символических ссылок в следующих ограничениях:

• Символьные ссылки доступны только в Windows Vista и более поздних версиях.
• Символьные ссылки будут работать только с NTFS, а не с FAT.
• Вам нужно быть администратором и/или иметь привилегию SeCreateSymbolicLinkPrivilege.
• Символьные ссылки на удаленные файловые системы по умолчанию отключены.
• Написаны символические ссылки Windows.
• Многие программы не понимают символических ссылок (включая более старую версию Windows Explorer).

Подробнее подробности доступны в вики Git для Windows.

В старых версиях Git для Windows вручную вручную core.symlinks вручную до true после клонирования и reset вашего рабочего дерева вы получите сообщения об ошибках, похожие на

$ git reset --hard HEAD
error: unable to create symlink directory (Function not implemented)
error: unable to create symlink linux-links/this_is_a_symbolic_link_to_file (Function not implemented)
fatal: Could not reset index file to revision 'HEAD'.

В качестве побочного примечания клиент JGit не исследовал целевую файловую систему для поддержки символической ссылки до ее версии 3.3, поэтому параметр core.symlinks возвращался к любой конфигурации системы/глобального Git. Начиная с версия 3.3 JGit-зонды для поддержки символической ссылки, но, похоже, слишком консервативны, установка core.symlinks = false в некоторых случаях, когда символические ссылки будут фактически поддерживаться.

Вы можете проверить https://github.com/sschuberth/git-playground, который содержит кучу ссылок, созданных в Linux для тестирования.

Ответ 2

У одного решения будет фильтр, чтобы обнаружить символические ссылки, хранящиеся в Git, и заменить их символической связью Windows.
Это подробно описано в "Git Symlinks в Windows"

Тем не менее, настоящая поддержка символической ссылки не только сейчас:
См. вопрос 224 и недавнее (июль 2012) обсуждение на GitHub (на что вы смотрели):

здесь три типа ссылок файловой системы в Windows: жесткие ссылки, соединения и символические ссылки.

• Жесткие ссылки и соединения доступны с NT. Hardlinks может указывать только на файлы, соединения только на каталоги (на том же томе).
• Символы, доступные с Vista, могут указывать на файлы или каталоги, также на разных томах.
• mklink, который поставляется с Vista, может создать все вышеперечисленное. Но способ, который он вызывается в script, делает его только созданием символических ссылок (что хорошо, ИМХО, поскольку они наиболее близко напоминают символические ссылки Linux).

Для pre-Vista нам понадобится резервная копия, которая либо создает жесткие ссылки для файлов с помощью "fsutil hardlink" (но, вероятно, только в том случае, если "ln" вызывается без "-s" ) и создает переходы для каталогов, fsutils reparsepoint "или просто вызывает оригинал ln.exe.

В дополнение к разрыву настроек Windows XP подобное изменение также нарушит стандартные настройки Windows 7, поскольку mklink требует привилегий администратора по умолчанию. Это можно исправить, проверяя, работает оно или нет, и возвращаясь к копированию в таких случаях.

Только для записи: я немного поиграл с попыткой сделать поддержку symlink в Git для самой Windows в последнее время, но в заключение пришел к выводу, что" поддержка символической ссылки" в Windows 7 и выше довольно близка к бесполезной для эмуляции Символы Unix.

Существует проект, утверждающий, что Open Source, 100% совместимый для Windows (и библиотеки точек доступа)", но:

К сожалению, обычные пользователи не имеют необходимых разрешений для создания символических ссылок по умолчанию в Windows. Объедините это с тем фактом, что вы не можете изменить то, на что указывает символическая ссылка, таким же образом, что требует POSIX, делает их более или менее бесполезными для нас. Это я уже писал выше.

Теперь авторы могут заявить, что они хотят, чтобы это было "на 100% совместимо" для всех, что мне небезразлично, но быстрый взгляд на исходный код показывает, что это не так. Они не предоставляют никаких резервных копий, они даже не загружают функцию CreateSymbolicLink динамически. Таким образом, результат на версиях Windows, не поддерживающих Symlink, будет сбой с отсутствующей ошибкой символа.

Ответ 3

Я работаю над поддержкой Symlink в msysgit здесь:

https://github.com/frogonwheels/git (ветвь mrg/symlink-v *.. в настоящее время v2)

Тесты не выполняются до завершения, и у меня есть ограниченное время для работы над ним, и нет реальной краткосрочной цели, чтобы мотивировать меня. Было бы неплохо иметь возможность использовать такие проекты, как git -annex в msysgit.

Моя работа затрудняется отсутствием поддержки symlink в оболочке msys.

Имеется командная строка для предоставления привилегий, предложенных командой cygwin ln. (Вам нужно будет запустить это как администратор).

editrights -a SeCreateSymbolicLinkPrivilege -a $YOUR_USER

Вся проблема символических ссылок каталога и файлов - это biggie.

В настоящий момент я придерживаюсь мнения, что, насколько мы можем, мы ограничимся созданием файловых символических ссылок... и не разрешаем символические ссылки в msysgit. Это не идеально, но реальность такова, что любое решение - это немного сложность, пытаясь навязать possix, связывающую реальности несовместимости NTFS с связью posix, просто больно.

Мы можем попытаться определить, является ли цель файлом или каталогом, но я могу думать о нескольких проблемах с этим чуть ли не в моей голове - особенно о всей проблеме того, какой порядок создаются сущностями.