Gumagana ang Git Clone sa Proxy, Ngunit Nabibigo ang Git LFS

Suriin nang hiwalay ang metadata at pag-download ng object ng Git LFS mula sa Git clone bago baguhin ang isang proxy na gumagana na.

Maaaring matapos ng clone ang paglilipat ng mga Git object habang wala pa ang LFS content nito. Nag-iimbak ang Git ng mga pointer file; gumagawa ang LFS client ng hiwalay na mga kahilingan para sa malalaking object.

Sa apektadong checkout na may naka-install na Git LFS, suriin ang endpoint nito at ang huling pagkabigo:

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

Suriin ang output nang lokal; ang mga URL ng repository at log ay maaaring magbunyag ng nagpapakilalang impormasyon o impormasyon sa pagpapatotoo. Tukuyin ang unang yugtong nabigo:

  1. Pakikipag-ugnayan sa LFS API.
  2. Pagkuha ng download action ng Batch API.
  3. Pag-abot sa download URL ng action na iyon, na maaaring gumamit ng ibang object-storage host at ng mga ibinigay na header.
  4. Paglipat ng object body.

Suriin ang mga override ng LFS endpoint ng repository pati na ang aktwal na URL. May sariling HTTP implementation, configuration, at minanang proxy environment ang LFS. Para sa Git LFS 3.7.0, sundin ang pagkakasunod-sunod ng pagpili ng proxy nito para sa aktwal na request URL. Ang pag-abot sa ordinaryong Git HTTPS host ay hindi sumusubok sa bawat kasunod na ruta ng object. Ang pagkabigo sa authentication ng object host ay iba rin sa proxy 407.

Kapag sinadya mo ang mga download, ang hiwalay na fetch sa isang kontroladong repository ay maaaring maghayag ng pagkabigo nang walang isa pang clone:

git -C project lfs fetch

Naglilipat ito ng mga object; hindi ito read-only na pagtatanong sa settings. Tiyakin na available ang kinakailangang content pagkatapos. Ang maliit na pointer na natitira sa isang partial checkout ay hindi ang malaking file, at ang naunang matagumpay na Git command ay hindi makapagpapatunay na natapos ang LFS transfer.

Kaugnay na mga artikulo