¿Qué significa el mensaje de error de git "El servidor no permite la solicitud de objetos no anunciados"?

Estoy tratando de hacer un pago desde github, y recibí este mensaje de error:

[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 ~]$

Entonces soy el mantenedor de estos repositorios. El src / http-parser es una bifurcación de otro repositorio, y los mantenedores de ese repositorio no han aceptado consistentemente mis solicitudes de extracción (sin dar razones) para agregar algunos archivos generados automáticamente al .gitignorearchivo. Pero no creo que ese sea el problema aquí.

git github

— vy32
fuente

Intenté el mismo comando y no hubo ningún error. ¿Todavía tienes un problema? Por cierto, en mi caso, comprobó diferentes confirmaciones:Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'

— ge0rdi

El problema se ha ido. Creo que significa que la referencia del submódulo era para un pago que no existe. Pero no estoy seguro.

— vy32

Como una nota para otros confundidos, pero este mensaje, puede surgir si actualiza un submódulo, actualiza un módulo principal al nuevo commit y nunca empuja el nuevo commit en el submódulo. ¡Entonces, por supuesto, tendrá problemas para verificar una confirmación que no existe en el control remoto del submódulo!

— Patrick Sanan

El problema parece ser que actualicé el submódulo, actualicé el repositorio principal, presioné el repositorio principal, pero no presioné el submódulo. Entonces, literalmente, el repositorio principal hizo referencia a una confirmación que no estaba en el repositorio del submódulo en github.

— vy32

Respuestas:

jgit: ¿cuáles son las referencias anunciadas de git? - Desbordamiento de pila :

Durante una búsqueda, el servidor puede enumerar las referencias que tiene y que el cliente puede querer buscar. Estas son las referencias anunciadas.

Parece que no puede obtener directamente ninguna confirmación específica del servidor, solo referencias (es decir, ramas y etiquetas). O más bien, que los servidores de Github están configurados para no permitir tales solicitudes.
Por lo tanto, si desea obtener una confirmación específica --depth, debe estar como máximo <depth>-1lejos de la referencia obtenida (que es la rama / etiqueta especificada en los metadatos del submódulo)

_{Por lo general, la gente aconseja establecer solo depthun número razonablemente grande pero aún mucho más pequeño que el número total de commit en el repositorio 50o 100. Por ejemplo, 50es lo que Travis usa cuando hace el clon inicial para el proyecto.}

Si no está actualizando el submódulo con --depth, no encontrar la confirmación significaría cualquiera de:

el árbol del submódulo está en estado "superficial" y se aplica lo anterior (solo es posible cuando se actualizó previamente --deptho su entrada en .gitmoduleshasshallow = true )
el commit no está en la rama que está usando el submódulo
el commit no está en el repositorio del submódulo en absoluto:
- o alguien cometió un error,
- o estuvo una vez allí pero fue eliminado por un empuje forzado

Para el registro, en su caso específico, fue el último caso: commit 5bbcdc5df9d01b521e8da011bab0da70bdec3653no está en el https://github.com/simsong/http-parser.gitrepositorio en absoluto.

— ivan_pozdeev
fuente

¿Qué es depth?

— vy32

@ vy32 agregó información para el caso cuando no está actualizando con --depth.

— ivan_pozdeev

"Una vez estuvo allí, pero fue eliminado por un impulso forzado", ¿hay algún recurso en esta situación?

— skolsuper

@skolsuper elige una confirmación diferente para recuperar. Por ejemplo, si se trata de un submódulo, cámbielo a una confirmación diferente en el superproyecto.

— ivan_pozdeev

Una forma de obtener acceso a un objeto no publicitado es sincronizar. Entonces, una actualización de submódulo debería funcionar, como:

git submodule sync --recursive
git submodule update

— tallista
fuente

+1 por simplicidad. para mí git submodule updatefalló en otro submódulo, pero cuando apliqué estas dos líneas a todos mis submódulos en el orden correcto , finalmente funcionó.

— Bizhan

Para superproyectos potencialmente grandes, se recomienda llevar a cabo $ git submodule sync --recursive; git submodule updateOR, si es justo después de clonar un control remoto, solo $ git submodule update --init --recursive. Esto atravesará de manera efectiva el árbol de archivos del proyecto desde /project/root/abajo, de acuerdo con lo que hay dentro /project/root/.gitmodules. Mucho más en $ git submodule --help...

— Cbhihe

Gracias @Cbhihe Editaré la respuesta para incluir la --recursivebandera.

— Carver