En proxy som bare gjelder lageret, høres rart ut før lageret finnes. Du trenger ikke å klone mislykket, redigere konfigurasjonen og starte på nytt.

Clone kan skrive en lokal innstilling før den første fetch:

git clone --config http.proxy=http://proxy.example.net:8080 \
  https://git.example.net/team/project.git project

Disse endepunktene er eksempler. For et offentlig HTTPS-lager på en tillatt offentlig proxy-rute, velg et HTTP-endepunkt fra HTTP-proxy-listen. Git dokumenterer at dette alternativet gjelder etter at det nye lageret er initialisert og før dets eksterne historikk hentes. For denne proxy-innstillingen kan den derfor dekke den første nedlastingen og bli værende i det nye lageret etterpå.

To like kommandoer etterlater ulike spor

For å gi ruten til én enkelt kjøring uten å lagre innstillingen i det klonede lageret, sett -c før underkommandoen:

git -c http.proxy=http://proxy.example.net:8080 \
  clone https://git.example.net/team/project.git project

git clone --config ... og git -c ... clone er ikke utskiftbare konfigurasjonsområder. Velg om fremtidige operasjoner i det lageret skal beholde proxyen.

Undersøk det nye lagerets lokale konfigurasjon når dette valget betyr noe. Andre bruker-, system- eller URL-spesifikke innstillinger kan fortsatt delta i den effektive politikken.

Hold passord utenfor disse eksemplene når du lagrer ruten. En verdi med legitimasjon som gis til clones konfigurasjonsalternativ, kan bli en permanent lagerinnstilling.

Dette er en HTTP-transportkonfigurasjon, inkludert HTTPS-fjernlagre. Et SSH-fjernlager trenger fortsatt sin SSH-proxy-rute; å flytte SSH til port 443 får ikke dette alternativet til å konfigurere det.

Relaterte artikler