O git clone funciona através do proxy, mas o Git LFS falha

Um clone pode terminar a transferência dos objetos Git enquanto o conteúdo LFS ainda está ausente. O Git armazena arquivos de ponteiro; o cliente LFS faz requisições separadas para os objetos grandes.

No checkout afetado com o Git LFS instalado, inspecione o endpoint e a última falha:

git -C project lfs env
git -C project lfs logs last

Revise a saída localmente; URLs de repositório e logs podem expor informações de identificação ou autenticação. Identifique o primeiro estágio que falhou:

1. Contatar a API do LFS.
2. Obter a ação de download da API Batch.
3. Alcançar a URL de download dessa ação, que pode usar um host de armazenamento de objetos diferente e cabeçalhos fornecidos.
4. Transferir o corpo do objeto.

Verifique as substituições de endpoint LFS do repositório, bem como a URL real. O LFS tem sua própria implementação HTTP, configuração e ambiente de proxy herdado. Para o Git LFS 3.7.0, siga sua ordem de seleção de proxy para a URL real da requisição. Alcançar o host HTTPS comum do Git não exercita todas as rotas de objetos posteriores. Uma falha de autenticação no host de objetos também é distinta de proxy 407.

Quando você pretende fazer os downloads, um fetch separado em um repositório controlado pode expor a falha sem outro clone:

git -C project lfs fetch

Isso transfere objetos; não é uma consulta de configurações somente leitura. Confirme que o conteúdo necessário está disponível depois. Um pequeno ponteiro que permanece em um checkout parcial não é o arquivo grande, e um comando Git bem-sucedido anterior não pode estabelecer que a transferência LFS foi concluída.