在Windows上使用符号链接克隆存储库时会发生什么?

And*_*rio 51 windows git symlink msysgit

有关在Windows上添加对符号链接的支持的问题很多.但是,当我在Windows上使用符号链接克隆存储库时实际发生了什么?

ssc*_*rth 50

从本机Git客户端的1.5.3版开始git clone,git init将探测目标文件系统以获得符号链接,并相应地设置本地存储库配置core.symlinks,即false用于FAT或NTFS.这使得在Linux下创建和提交的符号链接显示为包含Windows下链接文本的纯文本文件(有关详细信息,请参阅core.symlinks上git config文档).

Git for Windows 2.10.2版以来,安装程序有一个显式选项来启用符号链接支持.

在为Windows旧版本的Git,你可以手动设置core.symlinkstrue这使Git的创建在以下限制符号链接:

  • 符号链接仅适用于Windows Vista及更高版本.
  • 符号链接仅适用于NTFS,而不适用于FAT.
  • 您需要成为管理员和/或拥有SeCreateSymbolicLinkPrivilege权限.
  • 默认情况下禁用远程文件系统上的符号链接.
  • Windows的符号链接是键入的.
  • 许多程序不理解符号链接(包括旧版本的Windows资源管理器).

有关更多详细信息,请参阅Git for Windows wiki.

在为Windows手动设置旧版本的Git的core.symlinks手动true克隆和重置你的工作树后,你会得到类似的错误信息

$ 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'.
Run Code Online (Sandbox Code Playgroud)

另外,在版本3.3之前,JGit客户端没有探测目标文件系统的符号链接支持,因此core.symlinks设置回落到系统/全局Git配置的任何位置.从版本3.3开始,JGit探针支持符号链接,但似乎过于保守,core.symlinks = false 在某些情况下设置符号链接实际上是受支持的.

您可以查看https://github.com/sschuberth/git-playground,其中包含一系列在Linux上创建的链接以进行测试.

  • @ArnovanOordt 我在 Windows 10 中打开了开发人员模式(以允许非管理符号链接),将“core.symlinks”设置为“true”,并克隆了您的存储库,一切都按预期工作。目录和文件符号链接是在存储库中创建的。感谢您的演示存储库! (3认同)
  • 另请参阅此[pull request](https://github.com/msysgit/git/pull/172),了解如何向Git添加对符号链接的一些支持. (2认同)
  • 我正在使用win10和git 2.11.0。当我运行`git clone --config core.symlinks = true https:// github.com / sschuberth / sandbox.git`时,完全没有目录符号链接和this_is_a_symbolic_link_to_file。当使用core.symlinks = false时,文件在那里,但是显然不像正确的符号链接那样工作。我能够使用`mklink`手动创建符号链接,因此看来我拥有适当的权利。有谁知道为什么不检出/生成链接? (2认同)

Von*_*onC 11

一个解决方案将有一个过滤器,以检测Git存储的符号链接,并用Windows符号链接替换它们.
即在"详细Git的符号连接在Windows "

但是,真正的符号链接支持不仅仅是现在:
请参阅问题224和最近(2012年7月)关于GitHub(您看过)的讨论:

Windows上有三种类型的文件系统链接:硬链接,联结和符号链接.

  • 自NT以来,可以使用硬链接和连接.硬链接只能指向文件,只能指向目录(在同一卷上).
  • 自Vista以来可用的符号链接可以指向文件或目录,也可以指向不同的卷.
  • mklink自Vista发布以来,可以创建以上所有内容.但是在脚本中调用它的方式使得它只创建符号链接(这很好,恕我直言,因为它们最像Linux符号链接).

对于Vista之前,我们需要一个回退,使用" fsutil hardlink" 创建文件的硬链接(但可能只有在没有" -s"的情况下调用"ln ")并使用" fsutils reparsepoint" 创建目录的联结,或者只是调用原始文件ln.exe.

除了打破Windows XP设置之外,这样的更改还会破坏标准的Windows 7设置,因为mklink默认情况下需要管理员权限.这可以通过检查它是否有效来修复,并在这种情况下恢复复制.

仅仅是为了记录:我最近尝试在Git for Windows中进行符号链接支持,但最终得出的结论是,Windows 7及更高版本中的"符号链接支持"对于模拟Unix符号链接几乎没用.

有一个项目声称" 开源,100%兼容的Windows(和连接点库) ",但是:

遗憾的是,普通用户在Windows上默认没有创建符号链接所需的权限.将此与您无法以与POSIX要求相同的方式更改符号链接所指向的事实相结合,使它们对我们来说或多或少都无用.我已在上面写过.

现在,作者可以声称所有他们想要的是"我100%兼容",但是快速查看源代码就会发现它并非如此.它们不提供任何后备,甚至不CreateSymbolicLink动态加载函数.因此,非符号链接的Windows版本的结果将是一个丢失符号错误的崩溃.


小智 9

我一直在msysgit中处理Symlink支持:

https://github.com/frogonwheels/git(branch mrg/symlink-v*..目前为v2)

测试还没有完成,我只有有限的时间来处理它,并没有真正的短期目标来激励我.能够在msysgit下使用像git-annex这样的项目真好.

我的工作也因msys shell中缺少符号链接支持而受到阻碍.

有一个命令行用于授予cygwin ln命令建议的权限.(您需要以管理员身份运行它).

editrights -a SeCreateSymbolicLinkPrivilege -a $ YOUR_USER

Directory vs文件符号链接的整个问题是一个很大的问题.

目前我认为我们尽可能地限制自己使文件符号链接工作......并且不允许在msysgit中使用目录符号链接.它并不理想,但实际情况是,任何解决方案都是一个小问题,试图通过possix链接将可能链接到NTFS不兼容的现实只是痛苦.

我们可以尝试检测目标是文件还是目录,但我可以想到一些问题,尤其是实体创建顺序的整个问题.

  • @trysis:在NTFS上,如果创建文件符号链接,那么它只能指向一个文件。因此,如果您删除目标文件并将其替换为目录,则符号链接将被破坏。在 POSIX 上,符号链接仍然有效,因为 POSIX 符号链接不区分文件与目录。 (2认同)