A repository-local proxy sounds awkward before the repository exists. You do not have to clone unsuccessfully, edit its config and start over.

Clone can write a local setting before the initial fetch:

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

The endpoints are examples. For a public HTTPS repository on a permitted public-proxy route, select an HTTP endpoint from the HTTP proxy list. Git documents this option as taking effect after the new repository is initialized and before its remote history is fetched. For this proxy setting, it can therefore cover the first download and remain in the new repository afterward.

Two similar commands leave different footprints

To supply the route to one invocation without storing that setting in the cloned repository, put -c before the subcommand:

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

git clone --config ... and git -c ... clone are not interchangeable configuration scopes. Choose whether future operations in that repository should retain the proxy.

Inspect the new repository's local configuration when that choice matters. Other user, system or URL-specific settings can still participate in effective policy.

Keep passwords out of these examples when storing the route. A credential-bearing value passed to clone's configuration option can become a persistent repository setting.

This is an HTTP-transport configuration, including HTTPS remotes. An SSH remote still needs its SSH proxy route; moving SSH to port 443 does not make this option configure it.

Winndannde jowitiiɗe heen