Git error does not have a commit checked out

To expand on both the accepted answer from Mario Zigliotto and Albert’s answer, the reason this occurs is because of submodules. Here is a simple way to re-create the problem:

$ mkdir empty-submodule && cd empty-submodule
$ git init
Initialized empty Git repository in [path ending in empty-submodule/.git]
$ mkdir sub && (cd sub && git init)
Initialized empty Git repository in ... [path ending in empty-submodule/sub/.git]
$ ls
sub
$ ls -a sub
.       ..      .git
$ git add .
error: 'sub/' does not have a commit checked out
fatal: adding files failed

Note that the subdirectory sub is itself a Git repository, but no commit is checked out in this subdirectory. This is a simple statement of fact, true in this case because I created sub, went into it, and created a new, empty Git repository there. So that Git repository has no commits at all.

To the above fact, we add one more: No Git repository can hold another Git repository inside it. The reason for this has to do with security, but for our purpose here, the important side effect of this fact is that an attempt to add a sub-repository to a repository (like the superproject in empty-submodule) does not add the repository itself. Instead, it adds a reference to a commit within the repository. This is how submodules are implemented.¹ But to refer to some commit within the submodule, the submodule itself has to have some commit checked out.

The way to fix this really depends on the result you want. See the next section for more information about this.

¹Technically, submodules are implemented with two parts:

• Each commit in the superproject (the «outer» repository) has a reference to a commit within the submodule.
• In order to be able to run git clone on the submodule, the outer repository should also contain a .gitmodules file. This file will hold the instructions that tell the superproject Git how to git clone the submodule. Once the submodule repository exists, the superproject Git never needs to run git clone on it again. So it’s possible to accidentally, or on purpose, omit the .gitmodules file entirely.

Doing this produces a superproject that is difficult to use. I like to call this a half-assed submodule. If it were fully-assed, the superproject would be able to clone the submodule, but since the .gitmodules file is missing, it can’t.

Fixing the problem

There are multiple ways to fix the problem. Before you pick one, you should know whether you want to have a submodule. There’s no one correct answer here, as the question of should I use a submodule is a bit like which flavor of ice cream should I pick: different people have different preferences.

If you don’t want a submodule at all you will need to move or remove the .git subdirectory within the subdirectory in question, e.g.:

rm -rf sub/.git

(see also Nissan’s answer if using PowerShell on Windows).

Before you do that, you should:

1. Determine whether you want to keep the other repository. If so, do not remove it! Just move it somewhere else, e.g., mkdir ../keep && mv sub/.git ../keep.

2. Determine whether you need to git checkout some commit or branch before moving or removing the repository (the .git directory). If so, enter the submodule and check out the desired commit.

If you do want a submodule, you may need to make some commit(s) within the submodule, or check out some existing commit, just as in step 2 above. Once the submodule repository is on the correct commit, you can git add it.

Here is an example of creating a commit in my submodule named sub:

$ cd sub
$ echo this is the submodule > README.md
$ git add .
$ git commit -m initial
[master (root-commit) c834131] initial
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ cd ..

Now that the submodule has a commit, I can add it to the superproject. There’s a bit of a hitch here though, as I should also create the .gitmodule file mentioned in footnote 1 above. The git submodule add command does everything for you, but you need to know where you’ll git push this submodule repository. For instance:

$ git submodule add ssh://[email protected]/place/where/submodule/lives.git sub
Adding existing repo at 'sub' to the index

Everything is now ready to commit in the superproject:

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   .gitmodules
        new file:   sub

$ cat .gitmodules
[submodule "sub"]
        path = sub
        url = ssh://[email protected]/place/where/submodule/lives.git

The submodule has not actually been sent to GitHub yet. Before anyone else will be able to use the superproject, I’d have to create this GitHub repository, giving it sufficient (e.g., public) access, and git push the submodule commit to that GitHub repository. Then I can git push my commit in my superproject to whatever location that repository should live at. Then you—the generic «you»—can git clone the superproject, which now has a .gitmodules file with instructions by which your Git will be able to run git clone ssh://[email protected]/place/where/submodule/lives.git sub.

Submodules have a bunch of usability issues, with all of the above complications being one of them. Be sure you know what you’re getting into.

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.