How to fix: error: '<filename>' does not have a commit checked out fatal: adding files failed when inputting "git add ." in command prompt

I'm trying to add a ruby rails file to my repository in gitlab but it somehow wouldn't allow me to add the file saying that my file does not have commit checked out.

I've tried git pull, making the the file again and git adding but still wont work

error: '172069/08_lab_routes_controllers_views_172069_172188-Copy/adventure_game/' does not have a commit checked out
fatal: adding files failed

Solution 1:

If you have a subdirectory with a .git directory and try to git add . you will see this message.

This can happen if you have a git repo and then create/clone another repo in a subdirectory under that repo.

Solution 2:

I had the same error Message. I fixed it by deleting the file which causes the error from my Directory.

I hope this helps =)

Solution 3:

I had the same Error Message. I fixed it by command below:

git add folder-name/* instead of git add .

My Folder directory is like below:

Main-folder
 -folder-one
 -folder-two

ref: https://github.community/t/error-git-add/2937

Solution 4:

You don't need to delete the entire file from the directory as the first answer suggests, I just had to delete the .git directory, and then your git add . will work

This happens for the reason @Mario Zigliotto suggested, there is another repo in a subdirectory under that repo.

Solution 5:

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.