☰

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

tag-icon • tag-icon git github
O que significa a mensagem de erro do git "O servidor não permite solicitação de objeto não anunciado"?

Estou tentando fazer um checkout no github e recebo 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 analisador src/http é uma bifurcação de outro repositório, e os mantenedores desse repositório consistentemente não aceitaram minhas solicitações pull (sem motivos fornecidos) para adicionar alguns arquivos gerados automaticamente ao .gitignorearquivo. Mas não acho que esse seja o problema aqui.

Responder1

jgit - Quais são as referências anunciadas do git? - Estouro de pilha:

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

  • Parecevocê não pode obter diretamente nenhum commit específico do servidor, apenas refs (ou seja, ramificações e tags).Ou melhor, que os servidores Github estão configurados para proibir tais solicitações.

  • Então,se você deseja obter um commit específico com--depth, deve haver no máximo <depth>-1commits fora da referência buscada(que é o branch/tag especificado 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 commits no repositório - como 50ou 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 conseguir encontrar o commit significaria qualquer um dos seguintes:

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

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

Responder2

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

git submodule sync --recursive
git submodule update

Responder3

Isso pode acontecer quando você está apontando para o commit do submódulo que foi removido por meio de uma reescrita ou esmagamento do histórico. O melhor que você pode fazer é:

  • Primeiro, tenha uma ideia clara do que sua equipe está fazendo para saber como deve ser.
  • Atualize seu local com um git pull e encontre o commit mais próximo que funcione com sua ramificação (pode ser o mais recente) e adicione-o ao seu repositório pai. por exemplo, 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"

Quando você estiver satisfeito com a correção e sua equipe concordar, você pode aumentá-la e o erro deverá desaparecer.

Responder4

Para mim, isso tende a acontecer quando eu envio um repositório git pai de volta ao github sem enviar um submódulo que modifiquei e confirmei, mas não empurrei.

informação relacionada