Символические ссылки в каталоге заменяются символическими ссылками на файлы после нажатия и извлечения из Git - PullRequest
1 голос
/ 02 мая 2019

Символические ссылки в каталогах, созданные в Git-репозитории в Windows, по какой-то причине заменяются символическими ссылками на файлы после их отправки в Git и повторного клонирования.Это приводит к ошибке «Имя каталога неверно».

Однако это ТОЛЬКО происходит, когда символическая ссылка содержит более одного подкаталога в своем пути.Они продолжают работать нормально, если есть только один подкаталог.Кроме того, они все по-прежнему работают нормально в оболочке Bash.

Вот список в исходном репо:

05/01/2019  07:50 AM <SYMLINKD> ACN [..\..\acn\Installed]
05/01/2019  08:00 AM <SYMLINKD> ACNProxy [..\..\acnproxy\bin]
04/30/2019  01:29 PM <SYMLINKD> API [..\swupdate-2\bin]
05/01/2019  08:24 AM <SYMLINKD> AnalyticsPlugin [..\..\..\analyticsinstallerplugin]
05/01/2019  08:08 AM <SYMLINKD> Encryption [..\protocols\trunk\Encryption]
05/01/2019  08:17 AM <SYMLINKD> HelpFiles [..\helpwwb6]
05/01/2019  08:34 AM <SYMLINKD> PrePackagedDatabase [..\wwb6database]
05/01/2019  09:34 AM <SYMLINKD> ToastNotifications [..\toastnotifications]
05/01/2019  08:01 AM <SYMLINKD> acnComponent [..\..\..\acn_component]
05/01/2019  07:45 AM <SYMLINKD> dante_lic_mac [..\dante_mac_fix\WWB_compressed_lic_info_files]
05/01/2019  08:05 AM <SYMLINKD> devCategory [..\..\..\devicedescriptionfiles\devCategory]
05/01/2019  08:10 AM <SYMLINKD> shared [..\..\frequencycompat\FrequencyCompatibilityCalculator]
05/01/2019  09:26 AM <SYMLINKD> shared [..\..\swupdate\src\shared]
05/01/2019  08:06 AM <SYMLINKD> skuConversion [..\..\..\skuconversion\src]

После отправки символических ссылок на удаленный сервер Git и повторного репо, этисимволические ссылки, указывающие на путь, в котором имеется более одного подкаталога, были заменены символическими ссылками на файл:

05/01/2019  09:28 PM <SYMLINK>  ACN [..\..\acn\Installed]
05/01/2019  09:28 PM <SYMLINK>  ACNProxy [..\..\acnproxy\bin]
05/01/2019  09:28 PM <SYMLINK>  API [..\swupdate-2\bin]
05/01/2019  09:28 PM <SYMLINKD> AnalyticsPlugin [..\..\..\analyticsinstallerplugin]
05/01/2019  09:28 PM <SYMLINK>  Encryption [..\protocols\trunk\Encryption]
05/01/2019  09:28 PM <SYMLINKD> HelpFiles [..\helpwwb6]
05/01/2019  09:29 PM <SYMLINKD> PrePackagedDatabase [..\wwb6database]
05/01/2019  09:28 PM <SYMLINKD> ToastNotifications [..\toastnotifications]
05/01/2019  09:28 PM <SYMLINKD> acnComponent [..\..\..\acn_component]
05/01/2019  09:28 PM <SYMLINK>  dante_lic_mac [..\dante_mac_fix\WWB_compressed_lic_info_files]
05/01/2019  09:28 PM <SYMLINK>  devCategory [..\..\..\devicedescriptionfiles\devCategory]
05/01/2019  09:28 PM <SYMLINK>  shared [..\..\frequencycompat\FrequencyCompatibilityCalculator]
05/01/2019  09:28 PM <SYMLINK>  shared [..\..\swupdate\src\shared]
05/01/2019  09:28 PM <SYMLINK>  skuConversion [..\..\..\skuconversion\src]

Кто-нибудь может объяснить это поведение?

В оболочке Bash все символические ссылки выглядят одинаково(и функция) в исходном и клонированном репо:

lrwxrwxrwx 1 ******* 1049089 17 May  1 21:28 ./wwb6/API -> ../swupdate-2/bin
lrwxrwxrwx 1 ******* 1049089 46 May  1 21:28 ./wwb6/dante_lic_mac -> ../dante_mac_fix/WWB_compressed_lic_info_files
lrwxrwxrwx 1 ******* 1049089 19 May  1 21:28 ./wwb6/datastorage/ACN -> ../../acn/Installed
lrwxrwxrwx 1 ******* 1049089 18 May  1 21:28 ./wwb6/datastorage/ACNProxy -> ../../acnproxy/bin
lrwxrwxrwx 1 ******* 1049089 22 May  1 21:28 ./wwb6/datastorage/libdatastorage/acnComponent -> ../../../acn_component
lrwxrwxrwx 1 ******* 1049089 43 May  1 21:28 ./wwb6/datastorage/libdatastorage/devCategory -> ../../../devicedescriptionfiles/devCategory
lrwxrwxrwx 1 ******* 1049089 26 May  1 21:28 ./wwb6/datastorage/libdatastorage/skuConversion -> ../../../skuconversion/src
lrwxrwxrwx 1 ******* 1049089 29 May  1 21:28 ./wwb6/Encryption -> ../protocols/trunk/Encryption
lrwxrwxrwx 1 ******* 1049089 54 May  1 21:28 ./wwb6/FrequencyCompatibility/shared -> ../../frequencycompat/FrequencyCompatibilityCalculator
lrwxrwxrwx 1 ******* 1049089 11 May  1 21:28 ./wwb6/HelpFiles -> ../helpwwb6
lrwxrwxrwx 1 ******* 1049089 33 May  1 21:28 ./wwb6/Installation/Mac/AnalyticsPlugin -> ../../../analyticsinstallerplugin
lrwxrwxrwx 1 ******* 1049089 15 May  1 21:29 ./wwb6/PrePackagedDatabase -> ../wwb6database
lrwxrwxrwx 1 ******* 1049089 25 May  1 21:28 ./wwb6/SWUpdate/shared -> ../../swupdate/src/shared
lrwxrwxrwx 1 ******* 1049089 21 May  1 21:28 ./wwb6/ToastNotifications -> ../toastnotifications

Обратите внимание, что все это было сделано на компьютере с Windows 10.Однако удаленный репозиторий находится на сервере Linux.Умышленно у меня нет прав администратора на компьютере с Windows, потому что разработчики также не имеют этих прав, и символические ссылки должны работать на них.

Чтобы заставить работать символические ссылки в Windows, я сделал следующее:

  • Включена поддержка символьных ссылок при установке Git Bash;
  • Добавлены следующие записи в .bash_profile пользователя:

    export MSYS=winsymlinks:nativestrict

    export CYGWIN=winsymlinks:nativestrict

  • Включена поддержка символической ссылки в Git:

    git config --global core.symlinks true

  • Назначено разрешение SeCreateSymbolicLinkPrivilege путем добавления пользователя в политику создания символических ссылок с помощью редактора групповой политики;

  • Гарантировано, что пользователю разрешено оценивать локальные и локальные символические ссылки:

    fsutil behavior query symlinkevaluation

    ... и выполнил следующую команду от имени администратора, когда это не так:

    fsutil behavior set symlinkevaluation L2L:1

  • Для хорошей меры включены-c core.symlinks = true переключиться на команду git clone.

После внесения всех этих изменений создание и просмотр символьных ссылок каталога в Windows работает нормально, при этом пользователь не должен находиться в локальной папке.Админ группа.Пока они не были загружены в Linux и повторно загружены, то есть.

Обновление: символические ссылки, которые изменили тип с SYMLINKD на SYMLINK после клонирования, указывают на каталоги внутри подмодулей.Корневой каталог подмодуля создается при клонировании проекта контейнера, но его содержимое не удаляется, пока не завершится клон проекта контейнера (где находятся символические ссылки):

git clone --recursive -c core.symlinks=true ssh://<server>:7999/<repo>

ItПоявляется Windows, не воссоздает символические ссылки каталога, когда цель еще не существует.Вместо этого он создает их типа File symlink.Это работает из командной строки Windows, хотя (как в Linux):

mklink /d symlink ..\<some non-existing directory>\<another non-existing directory>

... работает нормально.

Мой текущий способ - просто удалить и восстановить их:

$ find . -type l -delete
$ git checkout .
Updated 14 paths from the index

Предпочел бы исправить это.

1 Ответ

2 голосов
/ 02 мая 2019

Похоже, что это нерешенная проблема, о которой сообщалось в git-for-windows / git проблема 1027

Создан неиспользуемый SYMLINK.
Даже если я создаюпозже в целевой директории символическую ссылку невозможно использовать из проводника Windows.

Более точная проблема, git-for-windows / git, проблема 1646 должна быть исправлена ​​в 2.17+.
Тем не менее, OP Jozef создал новую проблему: git-for-windows / git Issue 2177 .

Сопровождающий Йоханнес Шинделин (github.com/dscho) только что добавил:

Внутренняя модель данных Git, к сожалению, имеет очень Unix-ориентированное представление символических ссылок.
В Git для Windows мы обходим это, пытаясь определить тип изцель (если она существует).Это эвристический разрыв в вашем случае.

Однако недавно мы представили функцию, в которой вы можете объявить тип символической ссылки в .gitattributes: просто добавить строку в этот файл (или создать этот файл с этой строкой в ​​качестве содержимого).если он еще не существует):

my_symlink_name symlink=dir

Конечно, вы захотите добавить и зафиксировать этот файл.

Я моделировал строку .gitattributes после этой информации:

mklink /d symlink ..<some non-existing directory><another non-existing directory>

Первый столбец в .gitattributes всегда является именем файла или шаблоном имени файла

ОП подтверждает:

Это прекрасно работает на коробке Windows 10 с Git 2.21 (пришлось создавать 5 .gitattributes файлов)
Это не работает на коробке Windows 7 с Git 2.17.

Йоханнес отмечаетв Git для Windows v2.19.1 (5 октября 2018 г.)

Тип создаваемых символических ссылок (каталог или файл) теперь можно указать через .gitattributes.

См. commit 25a7f44 .

Символические ссылки:

В Windows символические ссылки имеют тип: «символическая ссылка файла»должен указывать на файл, а символьная ссылка на каталог должна указывать на каталог.Если тип символической ссылки не соответствует своему назначению, он не работает.

Git не записывает тип символической ссылки в индексе или в дереве.
При извлечении он будет угадывать тип, который работает, только если цель существует во время создания символической ссылки.Часто это может быть не так, например, когда ссылка указывает на каталог внутри подмодуля.

Атрибут symlink позволяет явно установить тип символической ссылки на file или dir,так что Git не должен угадывать.

Если у вас есть набор символических ссылок, которые указывают на другие файлы, вы можете сделать:

------------------------
*.gif   symlink=file
------------------------

Чтобы сообщить Git, что символическая ссылка указывает на каталог, используйте:

------------------------
tools_folder    symlink=dir
------------------------

Атрибут symlink игнорируется на платформах, отличных от Windows, поскольку они не различают разные типы символических ссылок.

...