Een proxy die alleen voor de repository geldt, klinkt onhandig voordat de repository bestaat. Je hoeft niet mislukt te klonen, de configuratie te bewerken en opnieuw te beginnen.

Clone kan vóór de eerste fetch een lokale instelling schrijven:

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

Deze eindpunten zijn voorbeelden. Kies voor een openbare HTTPS-repository op een toegestane openbare-proxyroute een HTTP-eindpunt uit de HTTP-proxylijst. Git documenteert dat deze optie geldt nadat de nieuwe repository is geïnitialiseerd en voordat de externe geschiedenis wordt opgehaald. Voor deze proxy-instelling kan die dus de eerste download omvatten en daarna in de nieuwe repository blijven.

Twee vergelijkbare opdrachten laten verschillende sporen

Om de route aan één aanroep te geven zonder de instelling in de gekloonde repository op te slaan, zet je -c vóór het subcommando:

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

git clone --config ... en git -c ... clone zijn geen uitwisselbare configuratiescopes. Kies of toekomstige bewerkingen in die repository de proxy moeten behouden.

Inspecteer de lokale configuratie van de nieuwe repository wanneer die keuze belangrijk is. Andere gebruikers-, systeem- of URL-specifieke instellingen kunnen nog steeds deelnemen aan het effectieve beleid.

Houd wachtwoorden buiten deze voorbeelden bij het opslaan van de route. Een waarde met inloggegevens die aan de configuratieoptie van clone wordt gegeven, kan een blijvende repository-instelling worden.

Dit is een HTTP-transportconfiguratie, inclusief HTTPS-remotes. Een SSH-remote heeft nog steeds zijn SSH-proxyroute nodig; SSH naar poort 443 verplaatsen zorgt er niet voor dat deze optie het configureert.

Gerelateerde artikelen