web-dev-qa-db-fra.com

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 que mon système de build ou mon code ne soit atteint, dès que mon script de build tente 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, tout commit commençant comme 0f5097...; Je n'ai aucune idée d'où cela vient SHA. Cet échec se produit uniquement sur les Linux travailleurs, et je ne peut pas comprendre pourquoi - git fetch --tags sur ce même repo 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 travailleurs Travis.

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

Édition 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 git fetch dans le référentiel parent. (Encore une fois, cet engagement, 0f509703, n'existe dans aucun des repo; encore une fois, exactement le même dépôt, exactement le même commit, et cela ne se produit pas sur macOS - uniquement sur les machines Linux de Travis.)

gittravis-cigit-submodules
10
ELLIOTTCABLE

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 une balise 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.
2
VonC