Git子模块:同一子模块是否必须跟踪子模块文件夹中的文件? [英] Git submodules : must a file located in a submodule's folder be tracked by that same submodule?

问题描述

我有一个包含子模块B的git repoA.文件file.c位于B的文件夹内，正如您所期望的那样，它本身位于A的文件夹内.问题:我可以从A而不是B跟踪此文件吗?那甚至有意义吗?

I have git repo A containing submodule B. A file file.c is located inside B's folder, itself inside of A's folder as you'd expect. Question : can I track this file from A and not from B ? Does that even make any sense ?

想法是B的任何用户都必须在B的文件夹层次结构的此特定位置添加自己的file.c.如果某人无法执行此操作，但仍将B添加为子模块，则B会简单地提及编译/运行时没有目标文件.

Idea is that any user of B has to add their own file.c in this specific location of B's folder hierarchy. If someone fails to do that but still adds B as submodule, B will simply mention that there is no target file upon compiling/running.

推荐答案

我有一个包含子模块B的git repo A.

I have git repo A containing submodule B.

换句话说，您可能会:

$ cd /path/to/A
$ ls
B/    README

(略显愚蠢)示例. (这里还有一个.gitmodules，但由于是点文件而被隐藏了.)

for (slightly silly) example. (There's also a .gitmodules here but it is hidden away since it is a dot-file.)

文件file.c位于B的文件夹中，正如您所期望的那样，其本身位于A的文件夹中.问题:我可以从A而不是B跟踪此文件吗?甚至有道理吗?

A file file.c is located inside B's folder, itself inside of A's folder as you'd expect. Question: can I track this file from A and not from B? Does that even make any sense?

问题是有意义的，但是 answer 是一个响亮的否(轰鸣声).问题是在存储库A中表示子模块B的存在的方式.

The question makes sense, but the answer is a resounding No (boom, thud). The problem is the way the existence of submodule B is represented within repository A.

存储库A的当前(HEAD)提交具有一个tree对象，该对象声明至少存在两个blob对象:

The current (HEAD) commit of repository A has a tree object that claims the existence of at least two blob objects:

• .gitmodules:此文件中包含存储库的URL，以及带有path
的path条目.
• B:此Blob具有模式160000("gitlink"条目).一旦Git克隆了URL以便B/存在，此Blob的内容"就是Git应该检出的提交哈希ID.大概，检查出哈希ID会得到一个名为file.c的文件，从而使B/file.c存在.

• .gitmodules: this file has in it the URL for a repository, along with a path entry that says B
• B: this blob has mode 160000 (a "gitlink" entry). The "contents" of this blob are the commit hash ID that Git should check out, once Git has cloned the URL so that B/ exists. Presumably, checking out that hash ID gets you a file named file.c, so that B/file.c exists.

要存储将被提取到超级项目A中的B/file.c中的blob的存在，Git需要在顶层树中存储另一个名为B的tree对象(第二个对象本身将具有一个名为file.c的blob，然后将其提取到B/file.c中).但是已经有一个名为B的gitlink blob对象，因此不能:不允许重复的名称.

To store the existence of a blob that would be extracted into B/file.c within the superproject A, Git would need to store a second tree object named B in the top level tree (this second tree object would itself have a blob named file.c, which would then be extracted into B/file.c). But there is already a gitlink blob object named B, so it can't: a duplicate name is disallowed.

想法是B的任何用户都必须在B的文件夹层次结构的此特定位置添加自己的file.c.如果某人无法执行此操作，但仍将B添加为子模块，则B会简单地提及编译/运行时没有目标文件.

Idea is that any user of B has to add their own file.c in this specific location of B's folder hierarchy. If someone fails to do that but still adds B as submodule, B will simply mention that there is no target file upon compiling/running.

您可以做的是在子模块存储库B中存储一个名为file.c的符号链接，该符号指向../user-supplied-file.c或../user/file.c或诸如此类.现在，存储库A需要包含user-supplied-file.c或user/file.c或链接指向的任何内容.

What you could do is store, in submodule repository B, a symlink named file.c, pointing to ../user-supplied-file.c or ../user/file.c or some such. Now repository A needs to contain user-supplied-file.c or user/file.c or whatever the link points to.

请注意，这将子模块与超级项目紧密耦合在一起.在这一点上，根本不理会子模块可能更合理.库和其他类似子模块的项通常不需要其他源代码；它们可能具有使用函数指针的例程，并通过这些指针调用这些函数，但是它们没有完全外部的源依赖项.

Note that this couples the submodule rather tightly with the superproject. At this point, it might be more reasonable not to bother with a submodule at all. Libraries and other such submodule-worthy items do not typically require additional source code; they might have routines that take function pointers, and call those functions through those pointers, but they don't have entirely-external source dependencies.

这篇关于Git子模块:同一子模块是否必须跟踪子模块文件夹中的文件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！