> On Thu, 28 Feb 2008, Ken.Fuchs@xxxxxxxxx wrote: > > > Unfortunately, this will not work because "git clone" is > > implemented by git-clone.sh and has no support for dealing > > with proxies at all. > > I fail to see why git-clone.sh, which uses git http-fetch > directly, should behave differently from git fetch, which > uses git http-fetch directly. Sorry, I wasn't very clear. When I said "git fetch" works, I meant only the proxy is initiated properly. "git fetch" itself still fails: fatal: Couldn't find remote ref HEAD As I understand it, this is due to "git clone" failing earlier. > I strongly suspect that you did not even try what I suggested. I know you were trying to help. I sincerely regret not thanking you in my earlier response to your suggestion. However, I had already tried your suggestion over a week ago (plus numerous user-id:password variants of the http_proxy environment variable). I also tried "git config http.proxy <proxy.domain>:<proxy-port>". I did not try "git config remote.<name>.proxy" which had an issue that was recently fixed via a patch submission a few days ago. > > So it seems that git's http protocol via a proxy isn't completely > > supported. > > If that should really be the case, well, Git is a programmers' tool, so > you should be perfectly able to find out what is happening _exactly_. Well, all git http proxy stuff is handled by curl, so GIT_CURL_VERBOSE=1 should get us pretty close to "what is happening _exactly_": $ GIT_CURL_VERBOSE=1 git clone http://www.kernel.org/pub/scm/git/git.git Initialized empty Git repository in /mnt/nfs/git/test-git/git/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? $ No verbose output from curl? How could that happen? Maybe GIT_CURL_VERBOSE=1 isn't logging all curl (especially proxy) actions? So, let's try tcpdump to see what's happening on the wire. In another shell (logged in as root), we start: "tcpdump -i eth0 | grep <proxy.domain>" We should at least see DNS lookup requests in the tcpdump for the <proxy.domain> if curl is using the proxy. We repeat the above "git clone" command and find that absolutely no proxy related traffic has been sent via eth0. (The above tcpdump pipe to grep generated no output whatsoever.) On the other hand, I know that "git fetch" does properly interact with the proxy, so as a benchmark, we repeat the tcpdump experiment with "git fetch". Now "tcpdump -i eth0 | grep <proxy.domain>" generates plenty of output, consisting of DNS requests/responses for <proxy.domain> and many packets between the git client and the proxy. Also, the command $ GIT_CURL_VERBOSE=1 git fetch http://www.kernel.org/pub/scm/git/git.git generates plenty of curl logging information (indicating successful proxy actions). Since Bogofilter thinks this type of output is SPAM, I won't try to include it all, but just the last 2 lines: * Connection #0 to host <proxy.domain> left intact fatal: Couldn't find remote ref HEAD Again, as I understand it, "git fetch" (which is proxy aware) is failing not due to proxy issues, but due to missing git filesystem structure that "git clone" (which is not proxy aware) needed to provide. If the necessary git filesystem structure existed in the local git repository, the "git fetch" command would probably succeed via http proxy. Before closing, I'll note that http.c was patched slightly to allow NTLM authentication via an http proxy server. The informal patches can be found earlier in this thread; they are clearly a work-in-progress. For example, proper user interface mechanisms (via "git config") still need to be developed/incorporated. Sincerely, Ken Fuchs -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
