Cargo registry-ի ներբեռնումներն աշխատում են, բայց Git կախվածությունները ձախողվում են

Cargo-ի պրոքսին փոխելուց առաջ կարդացեք ձախողված source URL-ը։ Registry metadata-ն, crate archive-ը և Git dependency-ն կարող են օգտագործել fetching և authentication տարբեր ուղիներ։ SSH Git URL-ին նաև HTTPS-ից տարբեր transport arrangement է պետք։

Cargo-ի համապատասխան HTTP requests-ի համար route-ը կարելի է սահմանել այսպես․

[http]
proxy = "http://203.0.113.10:8080"

Documentation endpoint-ը փոխարինեք ձեր HTTP proxy-ով։ Public proxy օգտագործելու թույլտվությամբ public registry path-ի թեկնածուները HTTP proxy list-ում են։ Սա չի ապացուցում, որ external Git executable-ը ստացել է նույն configuration-ը։

Եթե ձախողված source-ը Git է, Cargo-ն կարող է ընտրել Git CLI-ն՝ built-in implementation-ի փոխարեն․

[net]
git-fetch-with-cli = true

CARGO_NET_GIT_FETCH_WITH_CLI=true-ը այն ընտրում է մեկ command-ի համար։ External Git-ին այժմ պետք են սեփական proxy configuration և credentials։ Նույն launch environment-ում համեմատեք նույն Git URL-ը․ այլ terminal-ում աշխատող unrelated repository-ն թեստ չէ։

Missing revision-ը, repository permission denial-ը կամ SSH host-key error-ը implementation-ը փոխելուց հետո էլ նույն խնդիրն են։ Այս option-ը supported client է ընտրում, ոչ թե ընդհանուր dependency repair անում։

Diagnosis-ը պահեք project կամ command scope-ում․ global Git և user Cargo settings-ը կարող են ազդել այլ workspace-ների վրա։ Registry URL-ը ընտրում է package data, ոչ intermediary։ Git path-ի աշխատելուց հետո կրկին գործարկեք ամբողջ intended Cargo operation-ը, քանի որ archives-ը, redirects-ը և build-time downloads-ը կարող են այլ routes ավելացնել։