Git 将目录符号链接创建为文件

Question

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

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

我转换dir_b到相对符号链接指向dir_a（即rm -rf dir_b和ln -s dir_a dir_b，因此现在它看起来像：

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

在提交，推拉另一台机器后，我看到dir_b显示为普通文件而不是文件夹符号链接

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

尝试删除dir_b和恢复它，git checkout dir_b但它仍然作为文件重新创建，而不是文件夹符号链接。文件系统是支持符号链接的 ext4。事实上，git clone在同一个分区上进行刷新确实会dir_b像预期的那样创建一个符号链接。

以防万一，我会提到 的实际名称dir_b以点开头（例如.dir_b）。

git clone工作正常，因此我可以将其用作解决方法，但想知道究竟发生了什么以及恢复符号链接文件夹的正确方法是什么，因为显然git checkout symlinked_folder没有像原始存储库中那样重新创建文件夹。

Answer 1

在这种情况下的修复是运行：

git config core.symlinks true

（检查其他非默认设置可能是明智的，特别是如果 SD 卡存储库是由不同的操作系统创建的。）

正如评论中所讨论的，这里的关键元素是存储库最初是在不支持符号链接的文件系统上创建的，然后移动（手动复制）到支持符号链接的文件系统。 描述部分中的git config文档core.symlinks说：

如果为 false，符号链接将作为包含链接文本的小型纯文件检出。git-update-index(1)和git-add(1)不会将记录类型更改为常规文件。在像 FAT 这样不支持符号链接的文件系统上很有用。

默认为 true，除了git-clone(1)或git-init(1)将在创建存储库时探测并设置 core.symlinks false 。

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