Cargo-registerdownloads wurkje, mar Git-ôfhinklikheden mislearje

Lês de mislearre boarne-URL foardat jo Cargos proxy feroarje. Registermetadata, in crate-argyf en in Git-ôfhinklikheid kinne ferskillende ophel- en autentikaasjepaden brûke. In SSH Git-URL hat ek in oare transportynrjochting nedich as HTTPS.

Foar de relevante HTTP-oanfragen fan Cargo kin de rûte sa ynsteld wurde:

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

Ferfang it dokumintaasje-endpoint troch jo HTTP-proxy. Foar in iepenbiere registerrûte dêr’t iepenbiere proxies tastien binne, steane kandidaten yn de HTTP-proxylist. Dit lit net sjen dat in eksterne Git-útfierber deselde konfiguraasje krige.

As de mislearre boarne Git is, kin Cargo de Git CLI kieze ynstee fan syn ynboude ymplemintaasje:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true kiest dy foar ien kommando. De eksterne Git hat no syn eigen proxykonfiguraasje en gegevens nedich. Fergelykje deselde Git-URL yn deselde startomjouwing; in wurkjende, net-relatearre repository yn in oare terminal is net de test.

In ûntbrekkende revisy, wegere repositoryrjochten of in SSH-hostkeyflater bliuwt itselde probleem nei it wikseljen fan ymplemintaasje. De opsje kiest in stipe client, mar reparearret ôfhinklikheden net algemien.

Hâld de diagnoaze op projekt- of kommandonivo: globale Git- en Cargo-brûkersynstellingen kinne oare wurkromten beynfloedzje. In register-URL kiest pakketgegevens, net in tuskenpersoan. As it Git-paad wurket, rûn de folsleine bedoelde Cargo-operaasje opnij, om’t argiven, trochferwizings en downloads by it bouwen oare paden brûke kinne.