¿Qué significa "upload-pack: not our ref" cuando se obtienen referencias de git a través de --tags?

En uno de mis proyectos, las compilaciones de Travis fallan antes de que se pueda acceder a mi sistema de compilación o código, tan pronto como mi script de compilación intenta obtener todas las etiquetas Git con 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

Esto es especialmente confuso, ya que ni el repositorio principal bs-sedlexni el git-submodule ppx-sedlextienen ningún commit que comience como 0f5097...; No tengo idea de dónde viene ese SHA. Esta falla ocurre solo en los trabajadores de Linux , y no puedo entender por qué: git fetch --tagsen ese mismo repositorio funciona en los trabajadores de MacOS Travis, en mi máquina macOS y en una caja de Ubuntu Vagrant que hice para depurar esto.

¿Qué significa el error "fatal: error remoto: upload-pack: not our ref"; y cómo puedo solucionarlo? Ni siquiera estoy seguro de dónde comenzar a depurar este error, ya que solo ocurre específicamente en los trabajadores de Travis.

(Es poco probable que sea útil, pero aquí está el error en contexto y el repositorio en cuestión ).

Edición 1: Aquí hay algunos resultados interesantes adicionales, al agregar 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

No puedo ocultar por qué Git está solicitando un "objeto no publicitado" aquí; pero claramente no es un problema de GitHub, aquí, por alguna razón, el comando:

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

... se invoca automáticamente en el submódulo, cuando estoy git fetchen el repositorio principal. (Nuevamente, ese commit, 0f509703no existe en ninguno de los repositorios; nuevamente, exactamente el mismo repositorio, exactamente el mismo commit, y esto no está sucediendo en macOS, solo en las máquinas Linux de Travis).

Esto es especialmente confuso, ya que ni el repositorio principal bs-sedlex, ni el git-submodule ppx-sedlex, tienen ningún commit que comience como 0f5097 ...;

Pero podrían tener una etiqueta con ese SHA1 (que, una vez desreferenciado, apuntaría a una confirmación)

¿Qué significa el error "fatal: error remoto: upload-pack: not our ref";

Consulte " clonar un repositorio con submódulos anidados no funciona "

Git proporciona tres opciones que controlan si puede obtener una ID de objeto arbitrario:

• uno que permite buscar cualquier objeto arbitrario al que Git tenga acceso,
• uno que permite obtener cualquier objeto accesible desde una referencia,
• y uno que además permite obtener objetos accesibles desde referencias ocultas.

El mensaje "no es nuestra referencia" significa que está intentando obtener un objeto por ID de objeto, que se utiliza para submódulos, pero el servidor no lo permite.

En su caso, es posible que:

• o la etiqueta en el submódulo nunca fue presionada
• o (dado que funciona desde otras fuentes) Travis-CI no tiene acceso al submódulo ( dependencias privadas ): consulte " Git - Submódulos en Travis CI ".
  O tiene alguna versión en caché de ese submódulo.