当我运行WSL bash shell时，可以使用“ ln -s”命令创建符号链接。无论我在NTFS文件系统上还是WSL文件系统上工作，都将按预期方式创建符号链接。具体来说，WSL文件系统中的链接就像Linux符号链接一样工作，而NTFS文件系统中的符号链接是Windows符号链接，我可以在WSL和Windows中使用它。
对比符号链接在WSL中运行的git的Linux版本中的工作方式。我克隆了一个包含指向NTFS文件系统的符号链接的存储库。我不确定链接是什么，但绝对不是Windows符号链接。
有些人可能会说我应该使用Windows的Git，在克隆存储库时会创建正确的Windows符号链接。唯一的问题是我们拥有所有人都使用的bash脚本编写的工具，这些工具称为git。它们在Linux上可以正常工作，但是由于符号链接问题，从WSL来看它们不能达到预期的性能。我发现我需要所有命令行开发人员工具在WSL中运行，以便它们可以相互调用并传递文件路径和env vars等。因此，对于Windows运行Git真的不是我的选择。
是否有解决此问题的方法？如果WSL bash shell可以正常运行，那么在Linux版本的git中进行少量更改也可以解决此问题。这闻到Windows和Linux之间的某种哲学斗争。还是在Windows之前就存在Git的遗留问题...在这种情况下，肯定有一种方法可以为希望使用Windows符号链接的人启用符号链接的新处理。
这可能是Windows和Windows子系统（用于Linux的系统中的问题。）>
模拟的Linux环境使用symlink(2)系统调用创建符号链接，与ln -s命令非常相似。
之所以难以支持，是因为Windows符号链接的功能不如Unix符号链接。 Unix符号链接可以指向任何位置，而不管该位置上的对象是什么，并且目的地不必存在。 Windows符号链接则指向文件或目录，但固定为一种类型。
上游提供的标准Git，检查是否可以创建指向不存在的文件的符号链接。这很重要，因为Git不需要在符号链接之前检出目标文件。如果失败，则Git将core.symlinks设置为false，写的是带有符号链接内容的文件。发生此测试时，WSL无法创建正确类型的符号链接（因为没有目的地），因此操作失败。
Windows的Git可能具有一些功能，可以通过Windows中的符号链接解决此问题。它还具有大量的补丁程序，这些补丁程序未包含在上游发行的版本中，因此大多数Linux发行版都不使用该版本。
[我应该指出，有一个Linux发行版还发布了一个补丁，该补丁允许仅在符号链接指向用户（而不是其他任何人）拥有的文件时创建符号链接，并且它以相同的方式破坏事物。
您可以尝试在新的存储库中运行git config core.symlinks true，然后查看它是否按预期运行；可能会或可能不会。如果没有，您可以查看Git for Windows维护者是否将他们正在使用的修补程序发送给上游，并且它最终可能会包含在较新的Git版本中，并因此包含在较新的Linux版本中发行版。但是，由于Linux发行版通常提供稳定的版本，因此这将花费一些时间，通常需要数年，除非您下载较新的软件包。