我不认为你能从Git得到你想要的东西，但我真的不确定你想要什么（也不知道你为什么想要它）。
下面是子模块在Git中的实际工作方式。
假设R是一个充当超级项目的仓库。这意味着R至少有一个子模块S。R中的子模块S由以下组成：

• 这些指令存储在.gitmodules文件中，出现在R中的每个提交中，并在您要求Git这样做时从那里复制到R的.git/config。子模块“foo”的.gitmodules条目至少有以下两个子字段：

[submodule "foo"]
    path = path/to/foo
    url = https://github.com/owner/foo.git

字符串
(The子模块名称通常是“path/to/foo”，但我故意在这里做了一些手脚，以显示它们是如何分离的。）

• gitlink 在每个提交中的条目，在给定的路径下。

每个gitlink都包含一个“文件”（伪文件），其mode是160000，其存储的哈希ID是子模块存储库中提交的哈希ID。该文件的路径名在您git checkout提交后出现在Git的索引中。在上面的示例中，子模块“foo”将出现在索引中，名称为path/to/foo。1这里的hash ID将是git submodule update在S中git checkout的hash ID，通过执行：

(cd path/to/foo; git checkout $hash)

型
其中$hash是这个哈希ID。
现在，子模块S本身就是一个Git仓库。在过去，在git submodule absorbgitdirs之前，path/to/foo最终会包含一个名为.git的 * 目录 *，这是实际的仓库本身。path/to/foo的其余部分-一个目录-将简单地包含这个仓库的工作树。
通过从git submodule absorbgitdirs进行更改，S的 repository 现在位于R的repository之下，即在.git/本身中。在这里您将找到modules/子目录：.git/modules/foo将包含S的 repository。目录path/to/foo将包含一个名为.git的 * 文件 *，该文件包含此存储库的路径，加上用于当前 checkout 提交的所有文件，即用于储存库S的工作树。
现在假设S本身充当一个超级项目，子模块为T。这意味着，在S的工作树中，（驻留在path/to/foo中），有一个工作树.gitmodules; S中的提交有一个已提交的，冻结的.gitmodules副本;这个.gitmodules列出了子模块T的名称和一个相对于path/to/foo * 的路径 *。如果该子模块名为bar并且位于path = bar中，则来自R的工作树的相对路径是path/to/foo/bar。
R中的这个相对路径包含T的 work-tree。T的 repository 位于两个位置之一，这取决于你的Git版本：

• 预吸收-Git-dirs：path/to/foo/bar/.git;或
• 吸收后：.git/modules/foo/modules/bar。

注意兄弟子模块可能是相邻的：如果R有子模块S1和S2，它们的路径是path/to/s1和path/to/s2，则存储库本身和两个工作树在R的工作树中是相邻的。
还要注意，如果R有S和T作为子模块，而S有T作为子模块，那么您将得到 repository T的两个副本，一个在.git/modules/T中，一个在.git/modules/S/modules/T中（假设新的吸收布局）。你也会得到两个独立的工作树，但这显然是必要的，因为这两个代码可能有两个不同的提交被检出。如果吸收代码聪明并发现仓库T的重复，那就太好了，但它不是，也没有。
1请记住，在索引中，每个提交的文件都由一个具有四个条目的元组表示：

• name：文件的路径名，包括斜杠，例如path/to/foo或path/file.ext。
• 模式：通常是100644（常规文件）或100755（可执行文件）。你也可以有一个符号链接，在支持它的系统上，存储为模式120000，当然还有gitlinks，模式160000。
• 分段槽号：通常为零;非零数字表示您处于冲突合并中。
• hash ID：Git blob对象的hash ID，除了gitlink之外的所有情况下，这是子模块中提交的hash ID。