Git clone працуе праз проксі, але Git LFS не спраўляецца

Клон можа завяршыць перадачу аб'ектаў Git, а змест LFS пры гэтым можа заставацца адсутным. Git захоўвае файлы-паказальнікі; кліент LFS робіць асобныя запыты для вялікіх аб'ектаў.

У пацярпелым checkout са ўсталяваным Git LFS праверце яго endpoint і апошнюю памылку:

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

Прагледзьце вывад лакальна; URL рэпазіторыя і журналы могуць раскрыць ідэнтыфікацыйную або аўтэнтыфікацыйную інфармацыю. Вызначце першую няўдалую стадыю:

1. Зварот да API LFS.
2. Атрыманне дзеяння загрузкі ад Batch API.
3. Доступ да URL загрузкі гэтага дзеяння, які можа выкарыстоўваць іншы хост сховішча аб'ектаў і перададзеныя загалоўкі.
4. Перадача цела аб'екта.

Праверце пераазначэнні endpoint LFS у рэпазіторыі, а таксама фактычны URL. LFS мае ўласную рэалізацыю HTTP, канфігурацыю і ўспадкаванае асяроддзе проксі. Для Git LFS 3.7.0 выкарыстоўвайце яго парадак выбару проксі для фактычнага URL запыту. Дасягненне звычайнага хоста Git HTTPS не правярае ўсе наступныя маршруты аб'ектаў. Памылка аўтэнтыфікацыі хоста аб'ектаў таксама адрозніваецца ад памылкі проксі 407.

Калі вы маеце намер выканаць загрузкі, асобная fetch у кантраляваным рэпазіторыі можа паказаць памылку без чарговага клона:

git -C project lfs fetch

Гэта перадае аб'екты; гэта не запыт налад толькі для чытання. Пасля гэтага пераканайцеся, што патрэбны змест даступны. Маленькі паказальнік, што застаўся ў частковым checkout, не з'яўляецца вялікім файлам, і папярэдняя паспяховая каманда Git не можа даказаць, што перадача LFS завяршылася.