我有 git repo A 包含子模块 B. 一些文件file.c位于 B 的文件夹内，正如您所期望的，它本身位于 A 的文件夹内。问题：我可以跟踪这个文件吗file.c来自 A 而不是来自 B ？这有什么意义吗？
想法是 B 的任何用户都必须添加自己的file.c在 B 的文件夹层次结构的这个特定位置中。如果有人没有做到这一点，但仍然将 B 添加为子模块，B 将简单地指出编译/运行时没有目标文件。
我有 git repo A 包含子模块 B。
换句话说，您可能有：
$ cd /path/to/A
$ ls
B/ README
例如（有点愚蠢）。 （还有一个.gitmodules在这里，但它被隐藏起来，因为它是一个点文件。）
A file file.c位于 B 的文件夹内，正如您所期望的，它本身位于 A 的文件夹内。问题：我可以从 A 而不是从 B 跟踪该文件吗？这还有意义吗？
The question有道理，但是answer是一个响亮的No (轰隆声，轰隆声）。问题在于子模块 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 exists.
存储将被提取到的 blob 的存在B/file.c在超级项目内A，Git 需要存储第二个tree对象命名B在顶层树中（第二个tree对象本身有一个名为的 blobfile.c，然后将被提取到B/file.c）。但是已经有gitlink了blob对象命名B，所以不能：不允许使用重复的名称。
想法是 B 的任何用户都必须在 B 文件夹层次结构的这个特定位置添加自己的 file.c。如果有人没有做到这一点，但仍然将 B 添加为子模块，B 将简单地指出编译/运行时没有目标文件。
你可以做的就是在子模块存储库 B 中存储 asymlink named file.c， 指向../user-supplied-file.c or ../user/file.c或一些这样的。现在存储库 A 需要包含user-supplied-file.c or user/file.c或链接指向的任何内容。
请注意，这将子模块与超级项目紧密耦合。此时，根本不关心子模块可能更合理。库和其他此类值得子模块的项目通常不需要额外的源代码;他们可能有一些惯例函数指针，并通过这些指针调用这些函数，但它们不具有完全外部的源依赖项。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
