Git将目录符号链接(symbolic link)创建为文件

Question

给定 repo 中的两个普通文件夹:

drwx------ dir_a/
drwx------ dir_b/

我转换 dir_b指向指向 dir_a 的相对符号链接(symbolic link)(即 rm -rf dir_b 和 ln -s dir_a dir_b 现在看起来像:

drwx------ dir_a/
lrwxrwxrwx dir_b -> dir_a/

在另一台机器上提交、 push 和 pull 后，我看到 dir_b显示为普通文件而不是文件夹符号链接(symbolic link)

$ ls -al
drwx------ dir_a/
-rw------- dir_b

尝试删除 dir_b并使用 git checkout dir_b 恢复它但它仍然被重新创建为文件，而不是文件夹符号链接(symbolic link)。文件系统是支持符号链接(symbolic link)的 ext4。其实做个新鲜的 git clone在同一分区上创建 dir_b正如预期的那样作为符号链接(symbolic link)。

万一这很重要，我会提到 dir_b 的实际名称以点开头(例如 .dir_b )。
git clone工作正常，所以我可以使用它作为一种解决方法，但想知道到底发生了什么以及恢复符号链接(symbolic link)文件夹的正确方法是什么，因为显然 git checkout symlinked_folder不会像在原始存储库中那样重新创建文件夹。

Answer 1

在这种情况下，修复是运行:

git config core.symlinks true

(检查其他非默认设置可能是明智的，特别是如果 SD 卡存储库是由不同的操作系统创建的。)
正如评论中所讨论的，这里的关键元素是存储库最初是在不支持符号链接(symbolic link)的文件系统上创建的，然后移动(手动复制)到支持符号链接(symbolic link)的文件系统。 The git config documentation , 在描述 core.symlinks 的部分中，说:

If false, symbolic links are checked out as small plain files that contain the link text. git-update-index(1) and git-add(1) will not change the recorded type to regular file. Useful on filesystems like FAT that do not support symbolic links.

The default is true, except git-clone(1) or git-init(1) will probe and set core.symlinks false if appropriate when the repository is created.

一般来说， git clone 更安全一些。跨逻辑或物理驱动器移动存储库时，因为新克隆将探测新文件系统的设置。 Git 非常擅长自动检测其他更改(例如，索引对工作树路径进行编码)，并且这些设置中的大多数是特定于操作系统的，而不是特定于文件系统的。但是，如果您交叉引导不同的操作系统(或在虚拟机管理程序下运行它们)并在它们之间共享一些媒体，那么这些额外的 core.*设置可能会导致问题。参见，例如， core.fileMode和 core.protectNTFS .