33

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.

ifiht
  • 472
  • 1
  • 4
  • 11

7 Answers7

18

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.

torek
  • 448,244
  • 59
  • 642
  • 775
  • THANK YOU! That walked me through to the fix, posted the steps for my particular situation above. Still don't have any idea where that hash was coming from... – ifiht Apr 12 '20 at 09:08
  • 1
    I think this is often caused by submodule changes that have been made a new commit, and then hash ID added to the main repo which pushed to the remote, but accidentally not pushed to its own remote repo. Then when you clone the main repo, you'll find this commit just get lost. In a nutshell, this is caused by push main repo without --recurse-submodules option. – Neal.Marlin Apr 27 '22 at 03:28
8

Please try this git submodule foreach --recursive git reset --hard

hobbydev
  • 1,513
  • 19
  • 31
7

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.

James John McGuire 'Jahmic'
  • 11,728
  • 11
  • 67
  • 78
4
git submodule update --remote

then

git commit && git push

Everything will be ok

Suraj Rao
  • 29,388
  • 11
  • 94
  • 103
focus zheng
  • 345
  • 1
  • 4
  • 12
1

I faced this issue when I tried to update submodules on a branch that I created before branching some of the submodules. So I had repo1 branch-x, which has some submodlues, and only after that branch-x was created on some of the submodlues. My solution was to loop the submodules and reset the branches:

cd the-main-repo-dir
foreach submodlue in submodules do {
   cd {submodule path}
   git reset --hard origin/brnach-x
   cd -
}
git submodule update --init --recursive
git push origin/branch-x
hagits
  • 359
  • 1
  • 3
  • 8
1

If you made commits on the submodule

...then a common problem is that you

  • ...added that commit to the superproject,
  • pushed the superproject,
  • but did not push the submodule.

So everything is fine in your local workspace, but the superproject is referring to a submodule commit that does not (yet) exist on the remote machine. This fact is what leads to the message.

Solution

git push --recurse-submodules=on-demand

Lutz Prechelt
  • 36,608
  • 11
  • 63
  • 88
0

I had the same error with our Submodules. Since the project is publicly available, to fixed this, I replace all the values in urls in .git/config and in their individual submodule config with the projects https instead of the ssh

ALBlancoIV
  • 1
  • 3