CODEWITHSUNDEEP
git
clarkk
clarkk

Reputation: 27689

push recursive submodules - upload-pack: not our ref

When trying to push to production this error is thrown

remote: Cloning into '/var/www/domain.com/php/repo/api/log'...
remote: fatal: remote error: upload-pack: not our ref fdbef7944df6b5e83715f8679395a852dc5faf5e
remote: Fetched in submodule path 'php/repo/api/log', but it did not contain fdbef7944df6b5e83715f8679395a852dc5faf5e. Direct fetching of that commit failed.

Paths to the repos

php/repo/api
php/repo/api/log <-- the repo nested inside another repo

hooks/post-receive

#/bin/sh
cd /var/www/domain.com
git --work-tree=. --git-dir=/var/git_repos/domain.com.git checkout master -f
git --work-tree=. --git-dir=/var/git_repos/domain.com.git submodule update --init --recursive

Upvotes: 0

Views: 2369

Answers (1)

torek
torek

Reputation: 488453

You've instructed another Git—the one on your server—to clone a submodule, which it did. Where it got the submodule is not something I can answer, but presumably, it used your .gitmodules file to get a URL for some third server, and ran git clone using that URL to create the submodule repository on your server.

Having created or updated that submodule on the server, you then had the server's submodule's Git try to check out a specific commit, namely the one whose hash ID is fdbef7944df6b5e83715f8679395a852dc5faf5e. Your server's submodule repository did not have fdbef7944df6b5e83715f8679395a852dc5faf5e in it. This is probably because the third server, from which the submodule on the server is cloned, also does not have it.

This is very hard to follow, but we can make it easier to follow if we give each Git repository a name. There are at least 5 repositories in all:

  • You have a superproject repository; we'll call him Fred.
  • Your superproject has a submodule. We'll call her Wilma.
  • Your server has a Git repository that also acts as a superproject. We'll call him Barney, though he's mainly really a clone of Fred (or vice versa).
  • Your server has a Git repository that acts as a submodule. We'll call this one Betty.
  • Betty is herself a clone, of course (because all Git repositories are clones). Who is she a clone of? That's what I don't know (but you can find out / control through your .gitmodules file), but we'll call her Ann Margrock.

What's going on here is that you made a new commit in Fred. This new commit calls for Wilma or Betty, as the submodule, to use commit fdbef7944df6b5e83715f8679395a852dc5faf5e. Presumably, you did actually make commit fdbef7944df6b5e83715f8679395a852dc5faf5e in Wilma.

You then had your Git push from Fred to Barney. Barney now has a commit in him that also calls for commit fdbef7944df6b5e83715f8679395a852dc5faf5e from his submodule. But his submodule is Betty.

To get fdbef7944df6b5e83715f8679395a852dc5faf5e, Betty can make a phone call to Ann Margrock. But if Ann doesn't have fdbef7944df6b5e83715f8679395a852dc5faf5e either, Betty won't get fdbef7944df6b5e83715f8679395a852dc5faf5e. When Barney commands Betty to check out fdbef7944df6b5e83715f8679395a852dc5faf5e, she will complain, saying that she can't do that.

The solution is to give commit fdbef7944df6b5e83715f8679395a852dc5faf5e, not to Barney, nor to Betty, but rather to Ann, because Betty is calling Ann to get it. So figure out who represents Ann here and make sure that Wilma sends fdbef7944df6b5e83715f8679395a852dc5faf5e to Ann.

Upvotes: 2

Related Questions