
Estoy intentando realizar 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 ninguna razón) para agregar algunos archivos generados automáticamente al .gitignore
archivo. Pero no creo que ese sea el problema aquí.
Respuesta1
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 tal vez desee recuperar. Estas son las referencias anunciadas.
- Parece queNo 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 este tipo de solicitudes.
Entonces,si desea obtener un compromiso específico con
--depth
, debe estar como máximo<depth>-1
comprometido lejos de la referencia obtenida(que es la rama/etiqueta especificada en los metadatos del submódulo)Por lo general, la gente recomienda establecer
depth
un número razonablemente grande pero mucho más pequeño que el número total de confirmaciones en el repositorio, como50
o100
. Por ejemplo,50
es lo que usa Travis cuando realiza el clon inicial del proyecto.
Si no está actualizando el submódulo con --depth
, no encontrar la confirmación significaría cualquiera de las siguientes cosas:
- El árbol del submódulo está en estado "superficial" y se aplica lo anterior (solo es posible cuando se actualizó previamente con
--depth
osu entrada en.gitmodules
tieneshallow = true
) - la confirmación no está en la rama que está usando el submódulo
- la confirmación no está en absoluto en el repositorio del submódulo:
- o alguien cometió un error,
- o alguna vez estuvo allí pero fue eliminado por un empujón forzado
Para que conste, en su caso específico, fue el último caso: la confirmación 5bbcdc5df9d01b521e8da011bab0da70bdec3653
no está en el https://github.com/simsong/http-parser.git
repositorio en absoluto.
Respuesta2
Una forma de obtener acceso a un objeto no anunciado es sincronizar. Entonces una actualización de submódulo debería funcionar, como:
git submodule sync --recursive
git submodule update
Respuesta3
Esto puede suceder cuando apunta a la confirmación de un submódulo que se eliminó mediante una reescritura o aplastamiento del historial. Lo mejor que puedes hacer es:
- Primero, obtenga una imagen clara de lo que ha estado haciendo su equipo para saber cómo debería verse.
- Actualice su local con un git pull y luego busque la confirmación más cercana que funcione con su rama (puede ser la más reciente) y luego agréguela a su repositorio principal. por ejemplo, algo como:
parent-repo$ git fetch
parent-repo$ cd submodule-a
submodule-a$ git pull
submodule-a$ git checkout best-commit-according-to-team-and-your-branch
submodule-a$ cd ../
parent-repo$ git status
...
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
(commit or discard the untracked or modified content in submodules)
modified: submodule-a (modified content)
...
git add submodule-a
git commit -m "updated submodule-a reference"
Una vez que esté satisfecho con que sea correcto y su equipo esté de acuerdo, puede subirlo y el error debería desaparecer.
Respuesta4
Para mí, esto tiende a suceder cuando envío un repositorio de git principal a github sin devolver un submódulo que modifiqué y comprometí, pero que no rechacé.