Git-klonado funkcias tra la prokurilo, sed Git LFS malsukcesas

Spuru Git LFS-metadatumojn kaj objektajn elŝutojn aparte de la Git-klonado antaŭ ol ŝanĝi alikaze funkciantan prokurilon.

Klonado povas fini transdonadon de Git-objektoj dum ĝia LFS-enhavo ankoraŭ mankas. Git konservas montril-dosierojn; la LFS-kliento faras apartajn petojn por la grandaj objektoj.

En la koncerna laborkopio kun Git LFS instalita, kontrolu ĝian finpunkton kaj la lastan fiaskon:

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

Rigardu la eligon loke; retejaj URL-oj kaj protokoloj povas malkaŝi identigajn aŭ aŭtentikigajn informojn. Identigu la unuan fiaskintan etapon:

  1. Kontakti la LFS-API.
  2. Akiri la elŝutan agon de la Batch-API.
  3. Aliri la elŝutan URL-on de tiu ago, kiu povas uzi alian gastigan servilon por objektoj kaj provizitajn HTTP-kapojn.
  4. Transdoni la korpon de la objekto.

Kontrolu la anstataŭigojn de la LFS-finpunkto de la deponejo same kiel la faktan URL-on. LFS havas sian propran HTTP-implementon, agordon kaj hereditan prokuran medion. Por Git LFS 3.7.0, sekvu ĝian prokur-elektan ordon por la fakta peto-URL. Aliri la ordinaran Git-HTTPS-gastigan servilon ne ekzercas ĉiun postan objekto-vojon. Aŭtentiga fiasko ĉe objekta gastiganto ankaŭ malsamas de prokurila 407.

Kiam vi intencas la elŝutojn, aparta fetch en kontrolita deponejo povas malkaŝi la fiaskon sen alia klono:

git -C project lfs fetch

Ĉi tio transdonas objektojn; ĝi ne estas nurlega agorda demando. Konfirmu, ke la bezonata enhavo poste disponeblas. Malgranda montrilo restanta en parta laborkopio ne estas la granda dosiero, kaj antaŭe sukcesa Git-komando ne povas pruvi, ke la LFS-transdono finiĝis.

Rilataj artikoloj