我有包含子模块 B 的 git repo A。一些文件 file.c 位于 B 的文件夹内，如您所料，它本身位于 A 的文件夹内。问题：我可以从 A 而不是 B 跟踪此文件 file.c 吗？这有什么意义吗？
想法是 B 的任何用户都必须在 B 的文件夹层次结构的这个特定位置添加他们自己的 file.c。如果有人没有这样做但仍然添加 B 作为子模块，B 将简单地提及编译/运行时没有目标文件。
【问题讨论】：
标签： git git-submodules git-add
我有包含子模块 B 的 git repo A。
换句话说，你可能有：
$ cd /path/to/A
$ ls
B/ README
对于（有点傻）的例子。 （这里还有一个.gitmodules，但它被隐藏了，因为它是一个点文件。）
A 文件
file.c位于 B 的文件夹内，如您所料，它本身位于 A 的文件夹内。问题：我可以从 A 而不是 B 跟踪此文件吗？这有什么意义吗？
问题是有道理的，但答案是一个响亮的否（轰隆隆）。问题在于子模块 B 的存在在存储库 A 中的表示方式。
存储库 A 的当前 (HEAD) 提交有一个 tree 对象，该对象声称至少存在两个 blob 对象：
.gitmodules：这个文件中有一个存储库的 URL，以及一个 path 条目，上面写着 B
B：这个 blob 的模式为 160000（一个“gitlink”条目）。这个 blob 的“内容”是 Git 应该检查的提交哈希 ID，一旦 Git 克隆了 URL 以便 B/ 存在。据推测，检查该哈希 ID 会为您获取一个名为 file.c 的文件，因此 B/file.c 存在。要存储将被提取到超级项目A 中的B/file.c 的blob 的存在，Git 需要在顶层树中存储第二个名为B 的tree 对象（这第二个@987654338 @object 本身将有一个名为 file.c 的 blob，然后将其提取到 B/file.c)。但是已经有一个名为B的gitlink blob对象，所以不能：不允许重名。
想法是 B 的任何用户都必须在 B 文件夹层次结构的这个特定位置添加他们自己的 file.c。如果有人没有这样做但仍然添加 B 作为子模块，B 将简单地提及编译/运行时没有目标文件。
您可以做的是在子模块存储库 B 中存储一个名为file.c 的符号链接，指向../user-supplied-file.c 或../user/file.c 或类似的东西。现在存储库 A 需要包含 user-supplied-file.c 或 user/file.c 或链接指向的任何内容。
请注意，这将子模块与超级项目紧密结合在一起。在这一点上，根本不理会子模块可能更合理。库和其他此类具有子模块价值的项目通常不需要额外的源代码；它们可能具有采用函数指针的例程，并通过这些指针调用这些函数，但它们没有完全外部的源依赖关系。
【讨论】：