Que signifie «upload-pack: not our ref», lorsque vous récupérez les références git via --tags?

Dans l'un de mes projets, les builds Travis échouent avant qu'un de mes build-system ou code ne puisse être atteint, dès que mon build-script essaie de récupérer toutes les balises Git avec 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

Cela est particulièrement déroutant, car ni le référentiel principal bs-sedlex, ni le sous-module git ppx-sedlex, n'ont de commit commençant comme 0f5097...; Je n'ai aucune idée d'où vient ce SHA. Cet échec se produit uniquement sur les travailleurs Linux , et je ne peux pas comprendre pourquoi - git fetch --tagssur ce même dépôt fonctionne sur les travailleurs macOS Travis, sur ma machine macOS et sur une boîte Ubuntu Vagrant, j'ai tourné pour déboguer cela.

Que signifie l'erreur "fatal: erreur distante: upload-pack: not our ref"; et comment puis-je contourner ce problème? Je ne sais même pas par où commencer le débogage de cette erreur, car elle ne se produit que spécifiquement sur les employés de Travis.

(Il est peu probable que cela soit utile, mais voici l' erreur dans le contexte et le référentiel en question .)

Edit 1: Voici quelques résultats intéressants supplémentaires, en ajoutant 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

Je ne peux pas cacher ni expliquer pourquoi Git demande un "objet non annoncé" ici; mais ce n'est clairement pas un problème GitHub, ici - pour une raison quelconque, la commande:

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

... est automatiquement invoqué sur le sous-module, lorsque je suis git fetchdans le référentiel parent. (Encore une fois, ce commit, 0f509703n'existe dans aucun des repo; encore une fois, le même repo, le même commit exact, et cela ne se produit pas sur macOS - uniquement sur les machines Linux de Travis.)

Cela est particulièrement déroutant, car ni le repo principal bs-sedlex, ni le git-submodule ppx-sedlex, n'ont de commit commençant comme 0f5097 ...;

Mais ils pourraient avoir un tag avec ce SHA1 (qui, une fois déréférencé, pointerait vers un commit)

Que signifie l'erreur "fatal: erreur distante: upload-pack: not our ref";

Voir "le clonage d'un dépôt avec des sous-modules imbriqués ne fonctionne pas "

Git propose trois options qui contrôlent si vous pouvez récupérer un ID d'objet arbitraire:

• celui qui permet de récupérer tout objet arbitraire auquel Git a accès,
• celui qui permet de récupérer tout objet accessible à partir d'une référence,
• et un qui permet en outre de récupérer des objets accessibles à partir de références cachées.

Le message "not our ref" signifie que vous essayez de récupérer un objet par ID d'objet, qui est utilisé pour les sous-modules, mais le serveur ne le permet pas.

Dans votre cas, il est possible que:

• soit la balise dans le sous-module n'a jamais été poussée
• ou (puisqu'il fonctionne à partir d'autres sources) Travis-CI n'a pas accès au sous-module ( dépendances privées ): voir " Git - Sous-modules dans Travis CI ".
  Ou il a une version en cache de ce sous-module.