Git在添加主存储库之前恢复主存储库后未删除子模块

Posted 2021-04-13

这是怎么发生的：

1. 我签出了一个分支，其中添加了一个新的子模块。
2. 然后，当子模块无法添加时，我回到了另一个分支上的提交。
3. 现在我无法编译，因为检出的子模块仍在磁盘上；文件存在，如果我转到终端上的根目录，它仍然存在。

所以我该如何解决？当我返回从未存在的提交时，为什么不git删除该文件夹。

我尝试过：

• 主仓库上的[git submodule update。
• git reset --hard在子模块的仓库中。
• 主仓库中的[git reset --hard。

没有什么可以删除。我不想手动删除它，因为这不是git方法。

答案

那么我该如何解决？

[从工作树中手动删除所有子模块文件：例如rm -rf submodule。

为什么我回到以前从未存在过的提交时为什么没有git删除该文件夹。

子模块很乱。

记住，Git中的一个子模块实际上只是另一个Git存储库。这个其他Git存储库完全完全独立于您的主（超级项目）存储库。或更确切地说，可能是-您将只有两个并排的单独克隆，它们之间根本没有任何交互-除了您已将子模块克隆粘贴到superproject 。并且，在此过程中：

• 在现代Git中，存储库本身被“吸收”到超级项目的存储库目录中（因此，没有.git子-文件夹，而是工作中的.git file-子模块中已检出提交的树副本）。

• 超级项目的Git在超级项目的配置（不仅是.gitmodule文件）中而且在某些提交中记录了子模块的内容。特别是，在应该以某个特定哈希ID检出子模块的提交中，哈希ID本身作为gitlink条目存储在每个提交中。

• 超级项目的Git将cd插入子模块并执行git checkout <hash-id>，这将HEAD分离到子模块中。 （恰恰是[[when
，这是另一个问题；这取决于您是否启用了子模块递归。）

通常，子模块是一个（主要是）独立的存储库这一事实阻止了超级项目Git完全删除它。在这种特殊情况下，它可能应该

继续删除它，作为“将子模块更新为正确的提交”的一部分，因为相关子模块中的“正确”提交是“根本没有提交-删除工作树中的子模块”。过去，在Git将.git目录吸收到超级项目之前，这实际上会破坏子模块存储库，这很不好。

1在现代Git中，它不会（一旦子模块.git目录至少被吸收），因此可以正常使用。

---

1

在许多情况下，这是无害的，但需要重新克隆。但是，假设您通过以下方式进行了超级项目提交：（1）在您使子模块

in的新分支上提交子模块； （2）退出子模块回到超级项目，并更新索引gitlink条目，以在子模块中记录新的哈希ID； （3）进行新的提交。现在，您有一个子模块提交，该提交未在任何地方推送，但可以并且应该在推送超级项目提交之前进行推送。^{现在已经完成了所有设置，您决定看一下历史性提交。您在超级项目中git checkout <hash>，并且历史记录提交[[没有}

将该子模块检出。您已将submodule.recurse设置为true或已使用git checkout --recurse-submodules，以便超级项目将子模块带入正确的（缺少）提交，然后删除子模块。

因为.git目录的字面意思是存在于子模块in

中-在子模块的工作树内-这完全不可撤消地破坏了您在子模块上所做的提交，在您在那里进行的分支上，您尚未推。因此，此[[必须]]完成。现在.git目录本身位于其他地方，从超级项目的工作树中删除子模块不会损害子模块

repository

。所以现在，这种清除将很安全。将超级项目还原到最新提交，可以简单地还原子模块的工作树，检出由子模块的存储库的分支进行GC保护的提交（仍未推送）。