git submodules without .gitmodules file?

Question

Switching branches (using SourceTree), I get error messages like

fatal: No url found for submodule path '...' in .gitmodules

There is no .gitmodules file in the whole project.

Where should I look at?

SourceTree hits the following command upon branch switching:

git --no-optional-locks -c core.quotepath=false submodule update --init 

When I enter git submodules, the output is:

# git submodule                        
fatal: no submodule mapping found in .gitmodules for path '...'

Folder ... is empty.

Answer 1

What you have here is a broken submodule. (Or half a submodule? A submodule without instructions? It's not clear just what to call it—other than, as VonC notes, we can say that the gitlink half is a "gitlink", which at least is a searchable jargon term.)

A submodule, in Git, is a reference to another Git repository. In order to use the submodule, you must already have the other Git repository. In general, to make a Git repository, we mostly use git clone to copy some other, existing, repository. So normally, a submodule carries along with it the necessary instructions that Git will need in order to run git clone. These instructions go into the .gitmodules file.

If the .gitmodules file is missing, as in this case, it means that the instructions for setting up the submodule are missing. It's up to you whether to repair this by adding the instructions, or to repair it by removing the badly-formed submodule from your next commit.

Removing the half-formed submodule is easier. See VonC's accepted answer to No submodule mapping found in .gitmodule for a path that's not a submodule, but all you have to do is use git rm and then commit. This new commit will no longer refer to the submodule that cannot be cloned because the cloning instructions are missing. Subsequent new commits, built from this commit that doesn't mention the submodule, also won't mention the submodule (which continues to not exist).

Note that all existing commits remain broken. The only thing you can do about this is to remove (or replace) any existing broken commits, because no existing commit can be modified. It's generally not a great idea to try to fix or remove existing commits, as other people may be depending on them. A half-submodule / broken-submodule like this can be worked-with as a regular (non-broken) submodule if you have the other Git repository cloned into place.

To fix the problem by fixing the submodule, put the appropriate configuration into a new .gitmodules file and git add and git commit the .gitmodules file. The problem with actually doing this, of course, is that you need to know what the instructions are. Some of them are clear from the broken submodule, because the information in the .gitmodules file comes in several parts: one part is the path, which is just the name of the mode-160000 git ls-files entry (again, see VonC's answer). But the other part is the URL for the repository that should be cloned, and who knows what that might be?¹

---

¹In theory, whoever owns whichever repository you cloned to get into this situation should know—or, they should know who knows, or know someone who knows someone who knows, etc. But in practice, you get a lot of It was like that when I got here.