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

Question

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.)

Answer 1

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.