Git submodules : must a file located in a submodul

Question

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 ?

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.

Answer 1

I have git repo A containing submodule B.

In other words, you might have:

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

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

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?

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.

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

• .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.

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.

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.

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.