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

J'essaie de faire une vérification à partir de github, et j'ai reçu ce message d'erreur:

[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 dépôts. L'analyseur src / http est un fork d'un autre dépôt, et les responsables de ce dépôt n'ont toujours pas accepté mes demandes de tirage (sans raison donnée) pour ajouter quelques fichiers générés automatiquement au .gitignorefichier. Mais je ne pense pas que ce soit le problème ici.

jgit - Quelles sont les références annoncées par git? - Débordement de pile :

Lors d'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.

• Il semble que vous ne pouvez pas obtenir directement un commit spécifique du serveur, seulement des références (c'est-à-dire des branches et des balises). Ou plutôt, que les serveurs Github sont configurés pour interdire de telles demandes.

• Donc, si vous voulez obtenir un commit spécifique avec --depth, il doit être au plus <depth>-1éloigné de la référence récupérée (qui est la branche / balise spécifiée dans les métadonnées du sous-module)

  _{En règle générale, les gens conseillent de simplement définir depthun certain nombre raisonnablement grand mais toujours beaucoup plus petit que le nombre total de commit dans le repo-like 50ou 100. Par exemple, 50c'est ce que Travis utilise lors du clonage initial du projet.}

Si vous ne mettez pas à jour le sous-module avec --depth, ne pas trouver le commit signifierait:

• l'arborescence du sous-module est dans un état "superficiel" et ce qui précède s'applique (uniquement possible lorsqu'il a été précédemment mis à jour avec --depthou son entrée dans .gitmoduleshasshallow = true )
• le commit n'est pas sur la branche que le sous-module utilise
• le commit n'est pas du tout dans le référentiel du sous-module:
  • soit quelqu'un a fait une erreur,
  • ou il était une fois sur place mais a été supprimé par une poussée forcée

Pour mémoire, dans votre cas spécifique, c'était le dernier cas: commit 5bbcdc5df9d01b521e8da011bab0da70bdec3653n'est pas du tout dans le https://github.com/simsong/http-parser.gitrepo.

Une façon d'accéder à un objet non annoncé est de se synchroniser. Ensuite, une mise à jour du sous-module devrait fonctionner, comme:

git submodule sync --recursive
git submodule update