Following a lot of discussion on an msysGit issue and having researched this quite a bit myself I decided the state of proxying git on Windows could use some summarizing. In brief, it can be done for some circumstances and not for others. We will need some git patches to let everyone be able to operate over proxies.
Proxying the git protocol over an http proxy
The git protocol is a simple transport used over stream connections that is used when the repository URL begins with git://. This transport can be made to use a proxy by providing a command to handle the proxy connection. This is done by setting GIT_PROXY_CONNECTION or the core.gitproxy variable to point to some program that will make a connection to the git server on the target site. The connect program can be used for this purpose and creating a Windows command script like that below will use your http_proxy environment variable settings to open a connection through your http proxy and operate the git protocol over this connection.
@connect -h %*
There is a problem with this however. The way to make a direct connection through an http proxy is to issue the CONNECT command with the hostname and port of the target site. In this case we will be issuing CONNECT git.example.com:9418. Generally http proxies are configured to deny making connections to anything other than port 443 (the secure http port) and perhaps a limited set of additional ports (imaps is also common). So there is a good chance that your proxy will refuse this request and quite often it seems it will not bother to tell you either. If this is the case then you are restricted to using some other transport method unless your proxy admins will permit the git port.
Incidentally, it seems that curl cannot be used to make such a proxy tunnel. Curl provides good support for using proxies with and without authentication and even has a --proxytunnel option that will make it use the CONNECT method with the proxy to open a tunnel to the remote site. However it then always issues a GET request or some other request as specified by the --request option. It cannot be instructed just to silently pass data over this link once it is connected. For this reason we use the connect program as described above.
Proxying the git protocol over a SOCKS proxy
See the previous article for this but the essentials are that you set the SOCKS_SERVER environment variable to point to your SOCKS5 server and then use connect -s %* instead of using the -h option as above.
Proxying git using the http protocol
Git supports using the http protocol when the repository url uses the http:// scheme identifier. In this case it uses standard HTTP for the transport. HTTP can obviously be proxied so all that is necessary to use a proxy is to set the git variables or http_proxy environment variable. If authentication is required then this can be included in the proxy url (eg: http://userid:password@proxy.example.com:3128/. Alternatively curl supports the use of a .netrc file where authentication details can be recorded on a per hostname basis. On Windows this is called _netrc and needs to live in your HOME directory (a HOME environment variable may need to be created). The layout of the file is as below.
machine git.example.com login username password secret
Unfortunately it appears that curl will always use Basic authentication with the proxy. If your proxy needs something else, perhaps NTLM for a Windows network, then you have a problem. Curl is used to handle all the http transport details and this does support the NTLM authentication method but I know of no method to pass the necessary options to curl. Git makes use of curl via its library binding so it is not enought just to replace the curl executable with a wrapper script. It might be sufficient to compile the curl library with SSPI support. On windows this can be used to pass the logged in user authentication details to a program and usually works for NT domains with proxies that use NTLM. Otherwise it seems the http transport in git needs to have some variables added to control this.