我的存储库中有一个符号链接目录，它链接到文件系统上其他位置的文件。不管是什么原因，符号链接会时不时地断开，然后变成一个常规的空文件夹。所以我删除了空文件夹，并用ln -s ../../ ext重新创建了符号链接，这似乎起到了作用，因为我可以浏览该文件夹并查看其内容。但当我运行git status时，似乎ext文件夹中应该可见的所有文件都丢失了。我如何才能让git看到它们再次出现在符号链接目录中？
ln -s ../../ ext
git status
ext
顺便说一句，这是在Ubuntu 18上。
7gcisfzg1#
您的设置很奇怪，因为Git并不“遵循”符号链接，它只是“存储”它们。
也就是说，如果您有一个符号链接ext -> ../..并运行git add ext，Git会在索引中创建一个模式为120000(Symlink)的条目来存储BLOB内容../..。提交将创建一个提交，当提取该提交时，将创建指向../..的符号链接ext。当Git存储此符号链接时，它不会在ext中*存储任何文件。
ext -> ../..
git add ext
120000
../..
另一方面，如果您的现有提交包含名为ext/foo和ext/bar的文件，并且在此提交时克隆此存储库，或者将此提交提取到新的、否则为空的工作树中，Git将看到，为了写入名为ext/foo和ext/bar的文件，您的操作系统要求ext作为目录存在。因此，它将创建空目录ext，然后它将根据您的操作系统要求在其中创建文件foo和bar，以便创建到Git仅命名为ext/foo和ext/bar的文件。这两个名称ext/foo和ext/bar现在将在索引中，因此您进行的下一次提交也将包含这两个文件。
ext/foo
ext/bar
foo
bar
听起来很像你：
1.克隆了一个存储库(可能带有git clone --no-checkout？)；1.在工作树中手动创建了一个名为ext的符号链接，指向某个现有目录(可能是其中包含一些文件的目录)；1.说服git checkout创建ext/foo和ext/bar，而不首先删除符号链接ext并将其替换为目录ext。
git clone --no-checkout
git checkout
这不是受支持的操作模式1，当它出错时，您不应该感到惊讶。
1这会导致安全问题：Git的目的是不将任何文件写到工作树区域之外，而在指向工作树外目录的符号链接下写入文件将允许这种情况发生。Git并没有仔细限制符号链接的使用，而是通常一开始就不会存储“超出”任何链接的文件--尽管通过仔细操作索引以及在操作系统级别上您的工作树所在的文件系统，很可能会手动欺骗Git。
c7rzv4ha2#
只是不要把回购放在回购中，这不值得
2条答案
按热度按时间7gcisfzg1#
您的设置很奇怪，因为Git并不“遵循”符号链接，它只是“存储”它们。
也就是说，如果您有一个符号链接
ext -> ../..并运行git add ext，Git会在索引中创建一个模式为120000(Symlink)的条目来存储BLOB内容../..。提交将创建一个提交，当提取该提交时，将创建指向../..的符号链接ext。当Git存储此符号链接时，它不会在ext中*存储任何文件。另一方面，如果您的现有提交包含名为
ext/foo和ext/bar的文件，并且在此提交时克隆此存储库，或者将此提交提取到新的、否则为空的工作树中，Git将看到，为了写入名为ext/foo和ext/bar的文件，您的操作系统要求ext作为目录存在。因此，它将创建空目录ext，然后它将根据您的操作系统要求在其中创建文件foo和bar，以便创建到Git仅命名为ext/foo和ext/bar的文件。这两个名称ext/foo和ext/bar现在将在索引中，因此您进行的下一次提交也将包含这两个文件。听起来很像你：
1.克隆了一个存储库(可能带有
git clone --no-checkout？)；1.在工作树中手动创建了一个名为
ext的符号链接，指向某个现有目录(可能是其中包含一些文件的目录)；1.说服
git checkout创建ext/foo和ext/bar，而不首先删除符号链接ext并将其替换为目录ext。这不是受支持的操作模式1，当它出错时，您不应该感到惊讶。
1这会导致安全问题：Git的目的是不将任何文件写到工作树区域之外，而在指向工作树外目录的符号链接下写入文件将允许这种情况发生。Git并没有仔细限制符号链接的使用，而是通常一开始就不会存储“超出”任何链接的文件--尽管通过仔细操作索引以及在操作系统级别上您的工作树所在的文件系统，很可能会手动欺骗Git。
c7rzv4ha2#
只是不要把回购放在回购中，这不值得