[英]Git creates directory symlink as a file
Given two normal folders in a repo:给定一个 repo 中的两个普通文件夹:
drwx------ dir_a/
drwx------ dir_b/
I convert dir_b
to a relative symlink pointing to dir_a
(ie rm -rf dir_b
and ln -s dir_a dir_b
so that now it looks like:我转换
dir_b
一个相对符号链接指向dir_a
(即rm -rf dir_b
和ln -s dir_a dir_b
以至于现在它看起来像:
drwx------ dir_a/
lrwxrwxrwx dir_b -> dir_a/
After committing, pushing and pulling on another machine I see dir_b
shown as a normal file and not as a folder symlink在提交、推拉另一台机器后,我看到
dir_b
显示为普通文件而不是文件夹符号链接
$ ls -al
drwx------ dir_a/
-rw------- dir_b
Tried removing dir_b
and restoring it with git checkout dir_b
but it is still recreated as a file, and not a folder symlink.尝试删除
dir_b
并使用git checkout dir_b
恢复它,但它仍然作为文件重新创建,而不是文件夹符号链接。 The file system is ext4 which supports symlinks.文件系统是支持符号链接的 ext4。 In fact, doing a fresh
git clone
on the same partition does create dir_b
as a symlink as expected.事实上,在同一个分区上做一个新的
git clone
确实会像预期的那样创建dir_b
作为符号链接。
In case it could matter I'll mention that the actual name of dir_b
starts with a dot (eg .dir_b
).以防万一,我会提到
dir_b
的实际名称以点开头(例如.dir_b
)。
git clone
works correctly, so I could use it as a workaround, but would like to know what exactly is happening and what's the correct way to restore symlinked folders since apparently git checkout symlinked_folder
does not recreate the folder as in the original repo. git clone
工作正常,因此我可以将其用作解决方法,但想知道究竟发生了什么以及恢复符号链接文件夹的正确方法是什么,因为显然git checkout symlinked_folder
没有像原始存储库中那样重新创建文件夹。
The fix in this case was to run:在这种情况下的修复是运行:
git config core.symlinks true
(It may be wise to check for other non-default settings, especially if the SD-card repository was created by a different OS.) (检查其他非默认设置可能是明智的,特别是如果 SD 卡存储库是由不同的操作系统创建的。)
As discussed in comments, the key element here was that the repository was originally created on a non-symlink-supporting file system, and then moved (copied manually) to a symlink-supporting file system.正如评论中所讨论的,这里的关键元素是存储库最初是在不支持符号链接的文件系统上创建的,然后移动(手动复制)到支持符号链接的文件系统。 The
git config
documentation , down in the section describing core.symlinks
, says: git config
文档,在描述core.symlinks
的部分,说:
If false, symbolic links are checked out as small plain files that contain the link text.
如果为 false,符号链接将作为包含链接文本的小型纯文件检出。 git-update-index(1) and git-add(1) will not change the recorded type to regular file.
git-update-index(1)和git-add(1)不会将记录类型更改为常规文件。 Useful on filesystems like FAT that do not support symbolic links.
在像 FAT 这样不支持符号链接的文件系统上很有用。
The default is true, exceptgit-clone(1) or git-init(1) will probe and set core.symlinks false if appropriate when the repository is created.
默认为 true,除了git-clone(1)或git-init(1)将在创建存储库时探测并设置 core.symlinks false 。
In general, it's a little bit safer to git clone
a repository when moving it across logical or physical drives, since the new clone will probe the new file system's settings.通常,在跨逻辑或物理驱动器移动存储库时,
git clone
存储库更安全一点,因为新克隆将探测新文件系统的设置。 Git is fairly good at autodetecting other changes (eg, the index encodes the work-tree path) and most of these settings are OS-specific rather than file-system-specific. Git 非常擅长自动检测其他更改(例如,索引对工作树路径进行编码)并且这些设置中的大多数是特定于操作系统的,而不是特定于文件系统的。 If you cross-boot different OSes (or run them under hypervisors) and share some media between then, though, these additional
core.*
settings may cause issues.但是,如果您交叉启动不同的操作系统(或在虚拟机管理程序下运行它们)并在这两者之间共享一些媒体,这些额外的
core.*
设置可能会导致问题。 See, eg, core.fileMode
and core.protectNTFS
.参见,例如,
core.fileMode
和core.protectNTFS
。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.