在Windows上使用符号链接克隆存储库时会发生什么？
在Windows上添加对符号链接的支持方面存在很多问题。 但是，当我在Windows上使用符号链接克隆存储库时会发生什么？
从本地Git客户端的1.5.3版本开始 ， git clone和git init将探测目标文件系统的符号链接支持，并相应地为core.symlinks设置本地存储库configuration，即为FAT或NTFS设置为false 。 这使得在Linux下创build和提交的符号链接显示为包含Windows下链接文本的纯文本文件 （有关详细信息，请参阅有关core.symlink的git config文档 ）。
由于Git for Windows版本2.10.2 ，安装程序有明确的选项来启用符号链接支持 。
在Git for Windows的旧版本中，您可以手动将core.symlinks设置为true ，从而使Git能够在以下约束下创build符号链接：
- 符号链接仅在Windows Vista和更高版本上可用。
- 符号链接只适用于NTFS，而不是FAT。
- 您需要成为pipe理员和/或具有
SeCreateSymbolicLinkPrivilege权限。 - 远程文件系统上的符号链接默认是禁用的。
- Windows的符号链接是键入的。
- 许多程序不理解符号链接（包括旧版本的Windows资源pipe理器）。
更多的细节可以在Git for Windows wiki中find。
在旧版本的Git for Windows中，在克隆并重置工作树后手动将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'.
作为一个侧面说明，JGit客户端在版本3.3之前没有对目标文件系统的符号链接支持进行探测，因此core.symlinks设置回落到系统/全局Gitconfiguration。 从版本3.3开始，JGit针对符号链接支持进行探测，但似乎过于保守， 在实际上支持符号链接的某些情况下 ，将core.symlinks = false设置core.symlinks = false 。
您可以结帐https://github.com/sschuberth/git-playground ，其中包含一些在Linux上创build的链接进行testing。
一个解决scheme将有一个filter，以检测由Git存储的符号链接，并将其replace为Windows符号链接。
这在“ Windows中的Git符号链接 ”
但是，真正的符号链接支持不仅仅是现在：
请参阅问题224和最近（2012年7月） 关于GitHub的讨论 （您看过）：
这里有三种Windows上的文件系统链接：硬链接，连接和符号链接。
- 自NT以来，可以使用硬连接和连接。 硬链接只能指向文件，只能连接目录（在同一个卷上）。
- 自Vista以来可用的符号链接可以指向文件或目录，也可以指向不同的卷。
mklink自Vista以后发布，可以创build上述所有内容。 但是它在脚本中被调用的方式使得它仅创build符号链接（这是好的，恕我直言，因为它们最接近Linux符号链接）。对于Vista之前的版本，我们需要使用“
fsutil hardlink”创build硬fsutil hardlink（但可能只有在调用“ln”时不带“-s”）并使用“fsutils reparsepoint”创build目录结点，或者只需调用原始的ln.exe。除了破坏Windows XP的设置之外，像这样的改变也会破坏标准的Windows 7设置，因为默认情况下
mklink需要pipe理员权限 。 这可以通过检查是否工作来解决，并在这种情况下恢复为复制。为了logging：我最近尝试了在Git for Windows中为符号链接提供支持，但是最后得出结论：Windows 7中的“符号链接支持”对于模拟Unix符号链接是非常接近的。
有一个项目声称“ 开放源代码，100％兼容Windows（和Junction Point库） ”，但是：
不幸的是，普通用户在Windows上默认没有创build符号链接所需的权限。 结合这一点，你不能像POSIX所要求的那样改变一个符号链接指向的东西，使它们或多或less对我们无用。 这我已经写在上面。
现在，作者可以声称他们所有人都希望这是我所关心的“100％兼容”，但是快速查看源代码就可以发现，事实并非如此。 他们不提供任何回退，他们甚至不dynamic加载
CreateSymbolicLink函数。 因此，无符号链接Windows版本的结果将是一个丢失符号错误的崩溃。
我一直在msysgit这里工作Symlink支持：
https://github.com/frogonwheels/git（branch mrg / symlink-v * ..目前v2）
testing并没有完成，我的时间有限，没有真正的短期目标来激励我。 在msysgit下能够使用像git-annex这样的项目会很好。
我的工作也受到msysshell中缺less符号链接支持的阻碍。
有一个用于授予cygwin ln命令build议的权限的命令行。 （你需要以pipe理员身份运行）。
编辑权限-a SeCreateSymbolicLinkPrivilege -a $ YOUR_USER
目录与文件符号链接的整个问题是一个巨大的问题。
目前我认为，尽可能多的，我们只限于使文件符号链接工作…并且不允许msysgit中的目录符号链接。 这是不理想的，但现实是，任何解决scheme都是一个混乱，试图强加possix链接到NTFS不兼容与possix链接的现实是痛苦的。
我们可以尝试检测目标是文件还是目录，但是我可以从头到尾考虑一些问题 – 特别是实体创build顺序的问题。
