Why does git submodule update fail with "fatal: remote error: upload-pack: not our ref"?

I have a git repo with multiple submodules. I have tried deleting and adding the submodule in question (scopatz's nanorc), however the error persists across the deletion and re-addition. When I clone the repo to a new location I automatically update it with git submodule update --init --recursive, which is when this fails, but only for this submodule... Below is the relevant output from the command with GIT_TRACE=2:

23:01:26.918691 run-command.c:1569      run_processes_parallel: preparing to run up to 1 tasks
23:01:26.933567 run-command.c:1601      run_processes_parallel: done
23:01:26.934373 run-command.c:646       trace: run_command: git gc --auto
23:01:26.966805 git.c:344               trace: built-in: git gc --auto
23:01:26.991059 git.c:344               trace: built-in: git rev-parse --local-env-vars
23:01:27.015684 git.c:344               trace: built-in: git rev-parse --local-env-vars
23:01:27.032282 git.c:344               trace: built-in: git symbolic-ref -q HEAD
23:01:27.053948 git.c:344               trace: built-in: git config --get branch.master.remote
23:01:27.073636 git.c:344               trace: built-in: git fetch origin 151d94a8754b0a612315fc191c5373cc0055c13d
23:01:27.079657 run-command.c:646       trace: run_command: git-remote-https origin https://github.com/scopatz/nanorc.git
23:01:28.441725 run-command.c:646       trace: run_command: git rev-list --objects --stdin --not --all --quiet
23:01:28.452267 run-command.c:646       trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
23:01:28.467757 git.c:344               trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
fatal: remote error: upload-pack: not our ref 151d94a8754b0a612315fc191c5373cc0055c13d
fatal: The remote end hung up unexpectedly
Fetched in submodule path 'submodules/nano', but it did not contain 151d94a8754b0a612315fc191c5373cc0055c13d. Direct fetching of that commit failed.

hoping someone here can help, I'm mostly lost at this point.

=== EDIT: Solution Steps Below ===

cd {submodule path}
git reset --hard origin/master
cd -
git clean -n
git add {submodule path}
git commit
git submodule update --init --recursive

No errors, awesome.

Solution 1:

With Git and submodules, you start with a minimum of two Git repositories. One is "your" repository—the main one, which Git will call the superproject. The second Git repository is some other Git repository: there is nothing special about it at all. It's just that your superproject has in it these two parts:

• Instructions for cloning the submodule. That lets your Git run git clone if needed, during git submodule update --init for instance.

• The raw hash ID of some commit that should be in that other Git repository. Your main repository will, after cloning or running git fetch if appropriate in your clone of the other Git repository, run git checkout hash using this raw hash ID.

Your superproject is asking for the hash ID 151d94a8754b0a612315fc191c5373cc0055c13d in the Git repository you can clone from https://github.com/scopatz/nanorc.git. That commit simply does not exist in that repository, so it's not in any clone you make either.

Do you know why your superproject lists this commit hash ID, even though it does not exist? (I certainly don't.) You cannot get it from their Git, because they don't have it. That's what all these error messages are telling you.

You can try searching other repositories (or Google) for 151d94a8754b0a612315fc191c5373cc0055c13d (I just tried with Google and they can't find it). Or, if you don't really care specifically for that commit, try telling your own Git—your superproject—that it should get some other commit, one that does exist and therefore you can get.

Which commit should you get? I have no idea: that's up to you. Note that the place where your superproject lists the raw commit hash from the submodule is: in each commit. You can git checkout some commit, probably the tip of some branch, in your superproject. Then you can enter the submodule, pick a commit you like, use git checkout in that submodule—it's another Git clone, after all, so you can do any Git command there—to check out the desired commit. Then, exit the submodule (change directories back to your superproject) and run git add on the submodule path and git commit to record the new desired hash ID. This new commit now asks for that particular hash ID.

Solution 2:

This can happen if you don't fully commit and push your local changes to the submodules.

I got this error while cloning one of our repos with a submodule, while the original local repo was working fine. The problem was because I forgot the push the submodule changes.

So, make sure to commit and push all your submodule changes.