O que significa a mensagem de erro git "O servidor não permite solicitação de objeto não anunciado"?

Estou tentando fazer um checkout no github e recebi esta mensagem de erro:

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

Então, eu sou o mantenedor desses repositórios. O src / http-parser é uma bifurcação de outro repositório, e os mantenedores desse repositório não aceitaram consistentemente minhas solicitações de recebimento (sem nenhum motivo) para adicionar alguns arquivos gerados automaticamente ao .gitignorearquivo. Mas acho que não é esse o problema aqui.

git github

— vy32
fonte

Eu tentei o mesmo comando e não houve erro. Você ainda tem um problema? Btw no meu caso o check-out diferente comprometer:Submodule path 'src/http-parser': checked out '6b05cce82da5c4d407e5576ab892bc20a17b0394'

— ge0rdi

A questão se foi. Eu acho que isso significa que a referência do submódulo foi para um checkout que não existe. Mas eu não tenho certeza.

— vy32

Como uma observação para os outros confusos, mas esta mensagem, pode surgir se você atualizar um submódulo, atualizar um módulo pai para o novo commit e nunca enviar o novo commit no submódulo. Então, é claro, você terá problemas para verificar uma confirmação que não existe no controle remoto do submódulo!

— Patrick Sanan

O problema parece ser que eu atualizei o submódulo, atualizei o repositório pai, enviei o repositório pai, mas não o enviei. Então, literalmente, o repositório pai referenciou um commit que não estava no repositório do submódulo no github.

— vy32 18/10

Respostas:

jgit - O que são as referências anunciadas pelo git? - Estouro de pilha :

Durante uma busca, o servidor pode listar as referências que possui e que o cliente pode buscar. Estas são as referências anunciadas.

Parece que você não pode obter diretamente nenhum commit específico específico do servidor, apenas refs (ou seja, branches e tags). Ou melhor, que os servidores Github estão configurados para não permitir tais solicitações.
Portanto, se você deseja obter uma confirmação específica --depth, ela deve estar no máximo <depth>-1confirmada da referência buscada (que é a ramificação / tag especificada nos metadados do submódulo)

_{Normalmente, as pessoas aconselham definir apenas depthum número razoavelmente grande, mas ainda muito menor que o número total de confirmações no repositório 50ou no repositório 100. Por exemplo, 50é o que Travis usa ao fazer o clone inicial do projeto.}

Se você não estiver atualizando o submódulo com --depth, não encontrar o commit significa:

árvore do sub-módulo está em estado de "superficial" e situações acima se aplica (só é possível quando foi anteriormente atualizado com --depthou a sua entrada em .gitmodulestemshallow = true )
o commit não está no ramo que o submódulo está usando
o commit não está no repositório do submódulo:
- alguém cometeu um erro,
- ou já esteve lá, mas foi excluído por um empurrão forçado

Para o registro, no seu caso específico, foi o último caso: o commit 5bbcdc5df9d01b521e8da011bab0da70bdec3653não está no https://github.com/simsong/http-parser.gitrepositório.

— ivan_pozdeev
fonte

O que é depth?

— vy32

@ vy32 adicionou informações para o caso quando você não está atualizando --depth.

— precisa saber é o seguinte

"estava lá, mas foi excluído por um empurrão forçado" - existe algum recurso nessa situação?

— skolsuper 30/04

O @skolsuper escolhe um commit diferente para recuperar. Por exemplo, se esse era um submódulo, mude para um commit diferente no superprojeto.

— ivan_pozdeev 30/04

Uma maneira de obter acesso a um objeto não convertido é sincronizar. Em seguida, uma atualização do submódulo deve funcionar, como:

git submodule sync --recursive
git submodule update

— entalhador
fonte

+1 por simplicidade. para mim git submodule updatefalhou em outro submódulo, mas quando apliquei essas duas linhas em todos os meus submódulos na ordem correta , finalmente funcionou.

— Bizhan em

Para superprojetos potencialmente grandes, você deve executar $ git submodule sync --recursive; git submodule updateOU, se for logo após a clonagem de um controle remoto, apenas $ git submodule update --init --recursive. Isso atravessará efetivamente a árvore de arquivos do projeto de /project/root/baixo para cima, de acordo com o que está dentro /project/root/.gitmodules. Muito mais em $ git submodule --help...

— Cbhihe 18/10

Obrigado @Cbhihe, editarei a resposta para incluir a --recursivebandeira.

— carver