目录符号链接在推送和从Git中提取后更改为文件符号链接。

Question

由于某种原因，在Windows上的Git中创建的目录符号链接将更改为文件符号链接，一旦推到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服务器并重新克隆repo之后，指向有多个子目录的路径的符号链接被更改为File符号链接：

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 shell中，所有符号链接在原始的和克隆的回购中看起来都是相同的(和函数)：

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
• 通过使用组策略编辑器将用户添加到Create符号链接策略来分配SeCreateSymbolicLinkPrivilege权限；
• 确保允许用户评估本地到本地符号链接： fsutil behavior query symlinkevaluation

当情况并非如此时，...and以管理员身份运行以下命令：

fsutil behavior set symlinkevaluation L2L:1

• 为了获得更好的效果，请将-c core.symlinks=true切换到git克隆命令。

在进行了所有这些更改之后，在Windows中创建和遍历目录符号链接可以正常工作，而用户不必在Local组中。直到他们被推到Linux并重新下载。

Update:在克隆后将类型从SYMLINKD更改为SYMLINK的符号链接指向子模块中的目录。子模块的根目录是在克隆容器项目时创建的，但在容器项目的克隆完成( symlinks在其中)之后，内容才会被删除：

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

当目标还不存在时，Windows似乎不会重新创建目录符号链接。它将创建文件符号链接类型的它们。不过，这在Windows命令行中确实有效(就像在Linux中那样)：

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

...works很好。

我目前的解决办法是简单地删除和还原它们：

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

不过，我更希望能解决这个问题。

Answer 1

这似乎是一个悬而未决的问题，在git for windows/git发行1027中有报道

创建了不可用的SYMLINK。 即使稍后创建目标目录，从Windows资源管理器中也无法使用符号链接。

更准确的问题是，git for windows/git发行1646应该在2.17+中被修复。

尽管如此，OP Jozef还是创造了一个新的问题：git for windows/git发行2177。

维护人员约翰·辛德林(github.com/dscho)刚刚补充道：

不幸的是，Git的内部数据模型对符号链接有一个非常以Unix为中心的视图。 在中，我们通过尝试从目标(如果存在的话)确定类型来解决这个问题。在你的情况下这种启发式的突破。 但是，我们最近引入了一个特性，您可以在.gitattributes中声明符号链接类型:只需向该文件中添加一行(如果该文件尚不存在，则以该行作为内容创建该文件)： my_symlink_name symlink=dir 当然，您需要添加和提交这个文件。 在这些信息之后，我对.gitattributes行进行了建模： mklink /d符号链接。 第一列.gitattributes总是文件名或文件名模式。

“任择议定书”确认：

这在运行Git 2.21的Windows 10框上非常有效(必须创建5个.gitattributes文件) 它不能在运行Git 2.17的Windows 7机器上工作。

约翰斯向Git for Windows v2.19.1 (2018年10月5日)指出

要创建的符号链接类型(目录或文件)可以.gitattributes。

见提交25a7f44。

符号链接： 在Windows上，符号链接有一个类型:一个“文件符号链接”必须指向一个文件，一个“目录符号链接”必须指向一个目录。如果符号链接的类型与其目标不匹配，则不能工作。 Git不记录索引或树中符号链接的类型。 在签出时，它将猜测类型，只有在创建符号链接时目标存在时，该类型才能工作。这种情况通常不是这样的，例如，当链接指向子模块内的目录时。 symlink属性允许您显式地将符号链接类型设置为file或dir，因此Git不必猜测。 如果您有一组指向其他文件的符号链接，您可以这样做： -- *.gif symlink=file 若要告诉Git符号链接指向目录，请使用： -- tools_folder symlink=dir symlink属性在Windows以外的平台上被忽略，因为它们不区分不同类型的符号链接。