Git clone ເຮັດວຽກຜ່ານ proxy ແຕ່ Git LFS ລົ້ມເຫລວ

ຕິດຕາມ metadata ແລະ ການດາວໂຫລດ object ຂອງ Git LFS ແຍກຈາກ Git clone ກ່ອນທີ່ຈະປ່ຽນ proxy ທີ່ຍັງເຮັດວຽກຢູ່.

ການ clone ອາດຈະຖ່າຍທອດ object ຂອງ Git ສຳເລັດ ໃນຂະນະທີ່ເນື້ອຫາ LFS ຍັງຂາດຢູ່. Git ເກັບໄຟລ໌ pointer; ລູກຄ້າ LFS ສົ່ງຄຳຮ້ອງແຍກຕ່າງຫາກສຳລັບ object ຂະໜາດໃຫຍ່.

ໃນ checkout ທີ່ໄດ້ຮັບຜົນກະທົບ ທີ່ຕິດຕັ້ງ Git LFS, ກວດເບິ່ງ endpoint ແລະ ຄວາມຜິດພາດລ່າສຸດຂອງມັນ:

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

ກວດເບິ່ງ output ໃນເຄື່ອງ; URL ຂອງ repository ແລະ log ອາດເຜີຍຂໍ້ມູນລະບຸຕົວຕົນ ຫຼື ການພິສູດຢືນຢັນ. ລະບຸຂັ້ນຕອນທີ່ລົ້ມເຫລວທຳອິດ:

  1. ການຕິດຕໍ່ LFS API.
  2. ການໄດ້ຮັບ download action ຂອງ Batch API.
  3. ການໄປຮອດ download URL ຂອງ action ນັ້ນ, ເຊິ່ງອາດໃຊ້ host ເກັບ object ອື່ນ ແລະ header ທີ່ໃຫ້ມາ.
  4. ການຖ່າຍທອດເນື້ອຫາ object.

ກວດເບິ່ງການ override endpoint LFS ຂອງ repository ພ້ອມກັບ URL ຕົວຈິງ. LFS ມີການຈັດຕັ້ງ HTTP, ການຕັ້ງຄ່າ ແລະ ສະພາບແວດລ້ອມ proxy ທີ່ສືບທອດມາຂອງຕົນເອງ. ສຳລັບ Git LFS 3.7.0, ປະຕິບັດຕາມ ລຳດັບການເລືອກ proxy ຂອງມັນສຳລັບ URL ຄຳຮ້ອງຕົວຈິງ. ການໄປຮອດ host HTTPS ປົກກະຕິຂອງ Git ບໍ່ໄດ້ທົດສອບທຸກເສັ້ນທາງ object ຕໍ່ມາ. ຄວາມຜິດພາດການພິສູດຢືນຢັນຂອງ host object ກໍແຕກຕ່າງຈາກ proxy 407.

ເມື່ອທ່ານຕັ້ງໃຈດາວໂຫລດ, ການ fetch ແຍກໃນ repository ທີ່ຄວບຄຸມໄດ້ອາດເຜີຍຄວາມຜິດພາດໂດຍບໍ່ຕ້ອງ clone ອີກ:

git -C project lfs fetch

ສິ່ງນີ້ຖ່າຍທອດ object; ມັນບໍ່ແມ່ນຄຳຮ້ອງອ່ານການຕັ້ງຄ່າພຽງຢ່າງດຽວ. ຢືນຢັນວ່າເນື້ອຫາທີ່ຕ້ອງການມີຢູ່ຫຼັງຈາກນັ້ນ. pointer ນ້ອຍທີ່ຍັງເຫຼືອໃນ checkout ບາງສ່ວນບໍ່ແມ່ນໄຟລ໌ໃຫຍ່, ແລະ ຄຳສັ່ງ Git ທີ່ສຳເລັດກ່ອນໜ້າບໍ່ສາມາດຢືນຢັນວ່າການຖ່າຍທອດ LFS ສຳເລັດແລ້ວ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ