What does "upload-pack: not our ref" mean, when fetching git refs via --tags?

user_31897 0
Viewed 35720

In one of my projects, the Travis builds are failing before any of my build-system or code can be reached, as soon as my build-script attempts to fetch all of the Git tags with git fetch --tags:

`` git fetch --tags --verbose
POST git-upload-pack (350 bytes)
POST git-upload-pack (788 bytes)
POST git-upload-pack (797 bytes)
From https://github.com/ELLIOTTCABLE/bs-sedlex
 = [up to date]      fix-ci        -> origin/fix-ci
 * [new tag]         sedlex-1.99.2 -> sedlex-1.99.2
 * [new tag]         v1.99.3       -> v1.99.3
...
 * [new tag]         v20.0.0-pre.2 -> v20.0.0-pre.2
Fetching submodule ppx-sedlex
POST git-upload-pack (122 bytes)
From https://github.com/ELLIOTTCABLE/ppx-sedlex
 = [up to date]      develop       -> origin/develop
 = [up to date]      master        -> origin/master
...
 = [up to date]      v20.0.0-pre.2 -> v20.0.0-pre.2
POST git-upload-pack (4 bytes)
POST git-upload-pack (69 bytes)
POST git-upload-pack (586 bytes)
fatal: remote error: upload-pack: not our ref 0f509703fcd43ff4324d721a39220153bab49d4a

This is especially confusing, as neither the main repo bs-sedlex, nor the git-submodule ppx-sedlex, have any commit starting like 0f5097...; I have no idea where that SHA is coming from. This failure is occurring only on the Linux workers, and I can't figure out why — git fetch --tags on that same repo works on the macOS Travis-workers, on my macOS machine, and on an Ubuntu Vagrant box I spun-up to debug this.

What does the "fatal: remote error: upload-pack: not our ref" error signify; and how can I work around it? I'm not even sure where to begin debugging this error, as it only occurs specifically on Travis workers.

(It's unlikely to be helpful, but here's the error in context, and the repository in question.)

Edit 1: Here's some additional interesting output, from adding GIT_TRACE=2:

Fetching submodule ppx-sedlex
23:55:28.125076 git.c:439               trace: built-in: git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix ppx-sedlex/
23:55:28.125914 run-command.c:663       trace: run_command: git-remote-https origin https://github.com/ELLIOTTCABLE/ppx-sedlex.git
23:55:28.429609 run-command.c:663       trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
23:55:28.432485 run-command.c:663       trace: run_command: git rev-list --objects --stdin --not --all --quiet --alternate-refs
23:55:28.434082 git.c:439               trace: built-in: git rev-list --objects --stdin --not --all --quiet --alternate-refs
From https://github.com/ELLIOTTCABLE/ppx-sedlex
 = [up to date]      develop       -> origin/develop
 = [up to date]      master        -> origin/master
 = [up to date]      v1.99.4       -> v1.99.4
 = [up to date]      v1.99.4-pre.1 -> v1.99.4-pre.1
 = [up to date]      v1.99.4-pre.3 -> v1.99.4-pre.3
 = [up to date]      v1.99.4-pre.8 -> v1.99.4-pre.8
 = [up to date]      v2.0.0        -> v2.0.0
 = [up to date]      v20.0.0-pre.1 -> v20.0.0-pre.1
 = [up to date]      v20.0.0-pre.2 -> v20.0.0-pre.2
23:55:28.442482 run-command.c:1616      run_processes_parallel: preparing to run up to 1 tasks
23:55:28.442504 run-command.c:1648      run_processes_parallel: done
23:55:28.442536 run-command.c:663       trace: run_command: git gc --auto
23:55:28.443983 git.c:439               trace: built-in: git gc --auto
23:55:28.444903 run-command.c:663       trace: run_command: cd /home/vagrant/ELLIOTTCABLE/bs-sedlex/.git/modules/ppx-sedlex; unset GIT_PREFIX; GIT_DIR=. git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix ppx-sedlex/ origin 0f509703fcd43ff4324d721a39220153bab49d4a
23:55:28.446392 git.c:439               trace: built-in: git fetch --no-prune --no-prune-tags --tags -v --recurse-submodules-default on-demand --submodule-prefix ppx-sedlex/ origin 0f509703fcd43ff4324d721a39220153bab49d4a
23:55:28.447105 run-command.c:663       trace: run_command: git-remote-https origin https://github.com/ELLIOTTCABLE/ppx-sedlex.git
23:55:28.735871 run-command.c:663       trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --thin --no-progress https://github.com/ELLIOTTCABLE/ppx-sedlex.git/
23:55:28.738885 git.c:439               trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --thin --no-progress https://github.com/ELLIOTTCABLE/ppx-sedlex.git/
error: Server does not allow request for unadvertised object 0f509703fcd43ff4324d721a39220153bab49d4a

I can't make hide-nor-hair of why Git is requesting an "unadvertised object" here; but it's clearly not a GitHub problem, here — for some reason, the command:

git fetch --no-prune --no-prune-tags --tags -v \
   --recurse-submodules-default on-demand \ 
   --submodule-prefix ppx-sedlex/ \
   origin 0f509703fcd43ff4324d721a39220153bab49d4a

... is being automatically invoked upon the submodule, when I git fetch in the parent repo. (Again, that commit, 0f509703, does not exist in either repo; again, the exact same repo, the exact same commit, and this isn't happening on macOS — only on Travis's Linux machines.)

travis-ci git-submodules git
3 Answers

This is especially confusing, as neither the main repo bs-sedlex, nor the git-submodule ppx-sedlex, have any commit starting like 0f5097...;

But they might have a tag with that SHA1 (which, once dereferenced, would point to a commit)

What does the "fatal: remote error: upload-pack: not our ref" error signify;

See "cloning a repo with nested submodules does not work"

Git provides three options which control whether you can fetch an arbitrary object ID:

  • one which allows fetching any arbitrary object that Git has access to,
  • one which allows fetching any object reachable from a reference,
  • and one which additionally allows fetching objects reachable from hidden references.

The "not our ref" message means that you're trying to fetch an object by object ID, which is used for submodules, but the server doesn't allow it.

In your case, it might be possible that:

  • either the tag in the submodule was never pushed
  • or (since it is working from other sources) Travis-CI does not have access to the submodule (private dependencies): see "Git - Submodules in Travis CI ".
    Or it has some cached version of that submodule.
VonC_63090

I had the same error:

radato$ git submodule update 
fatal: git upload-pack: not our ref somehash0
fatal: remote error: upload-pack: not our ref somehash0
fatal: Fetched in submodule path 'dashboard', but it did not contain somehash0. Direct fetching of that commit failed.

So I deinitialized the submodule:

radato$ git submodule deinit -f dashboard
Cleared directory 'dashboard'
Submodule 'dashboard' (ssh://git@bitbucket.org/somedomain/dashboard.git) unregistered for path 'dashboard'

Now checking the summary I get

radato@$ git submodule summary 
* somepath1 somehash1 (2):
  < Merged in fixed_edge (pull request #2)
  < fixed broken test

* somepath2 somehash2 (2):
  < Merged in dsp_tx_freq (pull request #14)
  < Merged in v0.2.0 (pull request #13)

Eventually I pulled:

radato@$ git pull --prune --recurse-submodules --force 
Fetching submodule dashboard
Fetching submodule somepath1
Fetching submodule somepath2
Already up to date.
Submodule path 'somesubmodulepath1': checked out 'somehash1'
Submodule path 'somesubmodulepath2': checked out 'somehash2'

And now it works again. Here is the status

radato$ git status 
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean
user_7973960

In my case I solved the problem by doing git reset --hard <for sure more than 100 commits before ref>.

Then I simply did git pull and it worked. Since it worked right away with the procedure I didn't try any other, so I can't provide a deterministic approach to fix this.

user_90908370
Related