Git Clone Proxy Üzerinden Çalışıyor ama Git LFS Başarısız Oluyor

Zaten çalışan bir proxy'yi değiştirmeden önce Git LFS meta verilerini ve nesne indirmelerini Git clone'dan ayrı olarak izleyin.

Bir clone, Git nesnelerini aktarmayı bitirebilirken LFS içeriği hâlâ eksik olabilir. Git işaretçi dosyaları saklar; LFS istemcisi büyük nesneler için ayrı istekler yapar.

Git LFS kurulu olan etkilenen çalışma kopyasında, uç noktasını ve son hatasını inceleyin:

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

Çıktıyı yerel olarak inceleyin; depo URL'leri ve günlükler kimlik belirten veya kimlik doğrulama bilgilerini açığa çıkarabilir. İlk başarısız olan aşamayı belirleyin:

  1. LFS API ile iletişim kurma.
  2. Batch API'nin indirme eylemini alma.
  3. Bu eylemin indirme URL'sine ulaşma; bu URL farklı bir nesne depolama ana bilgisayarı ve sağlanan başlıkları kullanabilir.
  4. Nesne gövdesini aktarma.

Depo LFS uç nokta geçersiz kılmalarının yanı sıra gerçek URL'yi de kontrol edin. LFS'nin kendi HTTP uygulaması, yapılandırması ve devralınan proxy ortamı vardır. Git LFS 3.7.0 için gerçek istek URL'si açısından onun proxy seçim sırasını izleyin. Sıradan Git HTTPS ana bilgisayarına ulaşmak, sonraki her nesne rotasını sınamaz. Nesne ana bilgisayarında kimlik doğrulama hatası da proxy 407'den farklıdır.

İndirmeleri amaçladığınızda, kontrollü bir depoda ayrı bir fetch, başka bir clone olmadan hatayı ortaya çıkarabilir:

git -C project lfs fetch

Bu, nesneleri aktarır; salt okunur bir ayar sorgusu değildir. Gerekli içeriğin sonrasında mevcut olduğunu doğrulayın. Kısmi bir çalışma kopyasında kalan küçük bir işaretçi büyük dosya değildir ve daha önce başarılı olan bir Git komutu LFS aktarımının tamamlandığını kanıtlayamaz.

İlgili makaleler