Git clone fonctionne via le proxy, mais Git LFS échoue

Un clone peut avoir fini de transférer les objets Git alors que son contenu LFS manque encore. Git stocke des fichiers pointeurs ; le client LFS effectue des requêtes distinctes pour les objets volumineux.

Dans la copie de travail concernée où Git LFS est installé, examinez son point de terminaison et son dernier échec :

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

Examinez la sortie localement ; les URL de dépôt et les journaux peuvent révéler des informations d'identification ou d'authentification. Identifiez la première étape en échec :

1. Contacter l'API LFS.
2. Obtenir l'action de téléchargement de l'API Batch.
3. Atteindre l'URL de téléchargement de cette action, qui peut utiliser un hôte de stockage d'objets différent et des en-têtes fournis.
4. Transférer le corps de l'objet.

Vérifiez les substitutions de point de terminaison LFS du dépôt ainsi que l'URL réelle. LFS a sa propre implémentation HTTP, sa propre configuration et son environnement proxy hérité. Pour Git LFS 3.7.0, suivez son ordre de sélection du proxy pour l'URL de requête réelle. Atteindre l'hôte HTTPS Git ordinaire ne teste pas toutes les routes d'objets ultérieures. Un échec d'authentification sur l'hôte des objets est aussi distinct d'un proxy 407.

Si vous voulez réellement ces téléchargements, un fetch séparé dans un dépôt contrôlé peut révéler la panne sans refaire un clone :

git -C project lfs fetch

Cette commande transfère des objets ; ce n'est pas une simple lecture de configuration. Vérifiez ensuite que le contenu requis est disponible. Un petit pointeur qui reste dans une copie partielle n'est pas le fichier volumineux, et une commande Git réussie plus tôt ne prouve pas que le transfert LFS a abouti.