Git Clone : définir un proxy avant le premier fetch

Un proxy local au dépôt semble étrange avant que le dépôt existe. Pas besoin de cloner en échec, de modifier sa configuration et de recommencer.

Clone peut écrire un réglage local avant le premier fetch :

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

Ces points de terminaison sont des exemples. Pour un dépôt HTTPS public sur une route de proxy public autorisée, choisissez un point de terminaison HTTP dans la liste de proxies HTTP. Git documente que cette option s'applique après l'initialisation du nouveau dépôt et avant la récupération de son historique distant. Pour ce réglage de proxy, elle peut donc couvrir le premier téléchargement et rester ensuite dans le nouveau dépôt.

Deux commandes similaires laissent des traces différentes

Pour fournir la route à un seul appel sans stocker le réglage dans le dépôt cloné, placez -c avant la sous-commande :

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

git clone --config ... et git -c ... clone ne sont pas des portées de configuration interchangeables. Choisissez si les opérations futures dans ce dépôt doivent conserver le proxy.

Inspectez la configuration locale du nouveau dépôt lorsque ce choix compte. D'autres réglages utilisateur, système ou propres à une URL peuvent encore participer à la politique effective.

Gardez les mots de passe hors de ces exemples lors du stockage de la route. Une valeur porteuse d'identifiants transmise à l'option de configuration de clone peut devenir un réglage permanent du dépôt.

Il s'agit d'une configuration de transport HTTP, y compris les dépôts distants HTTPS. Un dépôt distant SSH a toujours besoin de sa route proxy SSH ; déplacer SSH sur le port 443 ne fait pas configurer cela par cette option.