{"thread":{"id":"12384","subject":"RE: FW: git via http protocol _and_ a proxy using NTLM authentication -- git 1.5.4.2 & curl 7.18.0","startedAt":"2008-02-29T20:06:49Z","lastAt":"2008-02-29T20:32:20Z","messageCount":2,"participants":["ken.fuchs@bench.com","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70413","messageId":"AA28F077645B324881335614E4F7C428034C15@win-ex01.bench.com","threadId":"12384","inReplyTo":null,"subject":"RE: FW: git via http protocol _and_ a proxy using NTLM authentication -- git 1.5.4.2 & curl 7.18.0","fromName":"","fromEmail":"ken.fuchs@bench.com","sentAt":"2008-02-29T20:06:49Z","receivedAt":"2008-02-29T20:06:49Z","isPatch":false,"sender":{"key":"ken.fuchs@bench.com","avatar":null},"body":"> On Thu, 28 Feb 2008, Ken.Fuchs@bench.com wrote:\n> \n> > Unfortunately, this will not work because \"git clone\" is\n> > implemented by git-clone.sh and has no support for dealing\n> > with proxies at all.\n> \n> I fail to see why git-clone.sh, which uses git http-fetch \n> directly, should behave differently from git fetch, which\n> uses git http-fetch directly.\n\nSorry, I wasn't very clear.  When I said \"git fetch\" works, I meant\nonly the proxy is initiated properly.  \"git fetch\" itself still fails:\n\nfatal: Couldn't find remote ref HEAD \n\nAs I understand it, this is due to \"git clone\" failing earlier.\n\n> I strongly suspect that you did not even try what I suggested.\n\nI know you were trying to help.  I sincerely regret not thanking\nyou in my earlier response to your suggestion.  However, I had\nalready tried your suggestion over a week ago (plus numerous\nuser-id:password variants of the http_proxy environment variable).\nI also tried \"git config http.proxy <proxy.domain>:<proxy-port>\".\nI did not try \"git config remote.<name>.proxy\" which had an issue\nthat was recently fixed via a patch submission a few days ago.\n\n> > So it seems that git's http protocol via a proxy isn't completely \n> > supported.\n> \n> If that should really be the case, well, Git is a programmers' tool,\nso \n> you should be perfectly able to find out what is happening _exactly_.\n\nWell, all git http proxy stuff is handled by curl, so GIT_CURL_VERBOSE=1\nshould get us pretty close to \"what is happening _exactly_\":\n\n$ GIT_CURL_VERBOSE=1 git clone http://www.kernel.org/pub/scm/git/git.git\nInitialized empty Git repository in /mnt/nfs/git/test-git/git/.git/\nCannot get remote repository information.\nPerhaps git-update-server-info needs to be run there?\n$\n\nNo verbose output from curl?  How could that happen?  Maybe\nGIT_CURL_VERBOSE=1 isn't logging all curl (especially proxy) actions?\n\nSo, let's try tcpdump to see what's happening on the wire.  In another\nshell (logged in as root), we start:\n\"tcpdump -i eth0 | grep <proxy.domain>\"\n\nWe should at least see DNS lookup requests in the tcpdump for the\n<proxy.domain> if curl is using the proxy.\n\nWe repeat the above \"git clone\" command and find that absolutely no\nproxy related traffic has been sent via eth0.  (The above tcpdump\npipe to grep generated no output whatsoever.)\n\nOn the other hand, I know that \"git fetch\" does properly interact with\nthe proxy, so as a benchmark, we repeat the tcpdump experiment with\n\"git fetch\".  Now \"tcpdump -i eth0 | grep <proxy.domain>\" generates\nplenty of output, consisting of DNS requests/responses for\n<proxy.domain> and many packets between the git client and the proxy.\n\nAlso, the command\n\n$ GIT_CURL_VERBOSE=1 git fetch http://www.kernel.org/pub/scm/git/git.git\n\ngenerates plenty of curl logging information (indicating successful\nproxy actions).  Since Bogofilter thinks this type of output is SPAM,\nI won't try to include it all, but just the last 2 lines:\n\n* Connection #0 to host <proxy.domain> left intact\nfatal: Couldn't find remote ref HEAD\n\nAgain, as I understand it, \"git fetch\" (which is proxy aware) is\nfailing not due to proxy issues, but due to missing git filesystem\nstructure that \"git clone\" (which is not proxy aware) needed to provide.\nIf the necessary git filesystem structure existed in the local git\nrepository, the \"git fetch\" command would probably succeed via http\nproxy.\n\nBefore closing, I'll note that http.c was patched slightly to allow\nNTLM authentication via an http proxy server.  The informal patches\ncan be found earlier in this thread; they are clearly a\nwork-in-progress.\nFor example, proper user interface mechanisms (via \"git config\") still\nneed to be developed/incorporated.\n\nSincerely,\n\nKen Fuchs\n"},{"id":"70420","messageId":"20080229203220.GB27217@glandium.org","threadId":"12384","inReplyTo":"AA28F077645B324881335614E4F7C428034C15@win-ex01.bench.com","subject":"Re: FW: git via http protocol _and_ a proxy using NTLM authentication -- git 1.5.4.2 & curl 7.18.0","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-02-29T20:32:20Z","receivedAt":"2008-02-29T20:32:20Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Feb 29, 2008 at 02:06:49PM -0600, Ken.Fuchs@bench.com wrote:\n> > On Thu, 28 Feb 2008, Ken.Fuchs@bench.com wrote:\n> > \n> > > Unfortunately, this will not work because \"git clone\" is\n> > > implemented by git-clone.sh and has no support for dealing\n> > > with proxies at all.\n> > \n> > I fail to see why git-clone.sh, which uses git http-fetch \n> > directly, should behave differently from git fetch, which\n> > uses git http-fetch directly.\n> \n> Sorry, I wasn't very clear.  When I said \"git fetch\" works, I meant\n> only the proxy is initiated properly.  \"git fetch\" itself still fails:\n> \n> fatal: Couldn't find remote ref HEAD \n> \n> As I understand it, this is due to \"git clone\" failing earlier.\n> \n> > I strongly suspect that you did not even try what I suggested.\n> \n> I know you were trying to help.  I sincerely regret not thanking\n> you in my earlier response to your suggestion.  However, I had\n> already tried your suggestion over a week ago (plus numerous\n> user-id:password variants of the http_proxy environment variable).\n> I also tried \"git config http.proxy <proxy.domain>:<proxy-port>\".\n> I did not try \"git config remote.<name>.proxy\" which had an issue\n> that was recently fixed via a patch submission a few days ago.\n> \n> > > So it seems that git's http protocol via a proxy isn't completely \n> > > supported.\n> > \n> > If that should really be the case, well, Git is a programmers' tool,\n> so \n> > you should be perfectly able to find out what is happening _exactly_.\n> \n> Well, all git http proxy stuff is handled by curl, so GIT_CURL_VERBOSE=1\n> should get us pretty close to \"what is happening _exactly_\":\n> \n> $ GIT_CURL_VERBOSE=1 git clone http://www.kernel.org/pub/scm/git/git.git\n> Initialized empty Git repository in /mnt/nfs/git/test-git/git/.git/\n> Cannot get remote repository information.\n> Perhaps git-update-server-info needs to be run there?\n> $\n\ngit clone is a shell script and doesn't put all the wrap-up around curl.\nGIT_CURL_VERBOSE is of no effect, and git http proxy settings won't work.\nOnly http_proxy environment variable will work.\n\nYou can try modifying git-clone and add --proxy-ntlm or --proxy-anyauth\nto curl calls, and set the http_proxy environment variable.\n\nAlternatively, you can try again with (work in progress) builtin-clone.c.\nhttp://thread.gmane.org/gmane.comp.version-control.git/75070/focus=75126\n\nMike\n"}]}