web-dev-qa-db-fra.com

Que signifie le message d'erreur git "Le serveur n'autorise pas la demande d'objet non annoncé"?

J'essaie de faire un paiement depuis github et j'ai reçu le message d'erreur suivant:

[user@Arch ~]$ git clone --recursive https://github.com/simsong/tcpflow.git
Cloning into 'tcpflow'...
The authenticity of Host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts.
remote: Counting objects: 4190, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 4190 (delta 21), reused 29 (delta 12), pack-reused 4146
Receiving objects: 100% (4190/4190), 50.27 MiB | 2.21 MiB/s, done.
Resolving deltas: 100% (2954/2954), done.
Submodule 'src/be13_api' (https://github.com/simsong/be13_api.git) registered for path 'src/be13_api'
Submodule 'src/dfxml' (https://github.com/simsong/dfxml.git) registered for path 'src/dfxml'
Submodule 'src/http-parser' (https://github.com/nodejs/http-parser.git) registered for path 'src/http-parser'
Cloning into '/home/user/tcpflow/src/be13_api'...
remote: Counting objects: 1203, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 1203 (delta 2), reused 5 (delta 1), pack-reused 1194
Receiving objects: 100% (1203/1203), 477.47 KiB | 1.96 MiB/s, done.
Resolving deltas: 100% (821/821), done.
Cloning into '/home/user/tcpflow/src/dfxml'...
remote: Counting objects: 1929, done.
remote: Total 1929 (delta 0), reused 0 (delta 0), pack-reused 1929
Receiving objects: 100% (1929/1929), 572.09 KiB | 2.89 MiB/s, done.
Resolving deltas: 100% (1294/1294), done.
Cloning into '/home/user/tcpflow/src/http-parser'...
remote: Counting objects: 1487, done.
remote: Total 1487 (delta 0), reused 0 (delta 0), pack-reused 1487
Receiving objects: 100% (1487/1487), 667.24 KiB | 2.46 MiB/s, done.
Resolving deltas: 100% (916/916), done.
Submodule path 'src/be13_api': checked out 'c81521d768bb78499c069fcd7c47adc8eee0350c'
Submodule path 'src/dfxml': checked out 'c31224626cf5f6678d42cbcfbfcd4e6191c9a864'
error: Server does not allow request for unadvertised object 5bbcdc5df9d01b521e8da011bab0da70bdec3653
Fetched in submodule path 'src/http-parser', but it did not contain 5bbcdc5df9d01b521e8da011bab0da70bdec3653. Direct fetching of that commit failed.
[user@Arch ~]$

Je suis donc le responsable de ces mises en pension. Le src/http-parser est un fork d'un autre référentiel, et les responsables de ce référentiel ont systématiquement refusé mes demandes d'extraction (sans raison) pour ajouter quelques fichiers générés automatiquement dans le fichier .gitignore. Mais je ne pense pas que ce soit le problème ici.

gitgithub
19
vy32

jgit - Quel est le type de référence annoncé par git? - Débordement de pile :

Pendant une extraction, le serveur peut répertorier les références qu’il possède et que le client peut souhaiter extraire. Ce sont les références annoncées.

  • Cela ressemble à vous ne pouvez pas obtenir directement une validation spécifique du serveur, uniquement des références (branches et balises). Ou plutôt, les serveurs Github sont configurés pour interdire de telles requêtes.

  • Donc, si vous voulez obtenir un commit spécifique avec --depth , vous devez avoir au plus <depth>-1 commits, loin de la référence extraite (qui est la branche/balise spécifiée dans les métadonnées du sous-module)

    En règle générale, il est conseillé aux utilisateurs de définir simplement depth sur un nombre raisonnablement important mais toujours beaucoup plus petit que le nombre total de validations dans le référentiel - comme 50 ou 100. Par exemple. 50 est ce que Travis utilise lors de la création du clone initial du projet.

Si vous ne mettez pas à jour le sous-module avec --depth, si vous ne trouvez pas le commit, cela signifie:

  • l'arborescence du sous-module est à l'état "peu profond" et ce qui précède s'applique (possible uniquement s'il a déjà été mis à jour avec --depth ou son entrée dans .gitmodules a shallow = true )
  • le commit n'est pas sur la branche utilisée par le sous-module
  • le commit n'est pas du tout dans le repo du sous-module:
    • soit quelqu'un a fait une erreur,
    • ou il était une fois là, mais a été supprimé par une poussée forcée

Pour mémoire, dans votre cas particulier, il s'agissait du dernier cas: commit 5bbcdc5df9d01b521e8da011bab0da70bdec3653 n'est pas du tout dans le référentiel https://github.com/simsong/http-parser.git.

5
ivan_pozdeev