Git over HTTPS can ls-list but cannot clone

Question

While this is a common question, this one is particlary different than the others, when I issue git ls-remote https://[e-mail]/myser/repo.git , it asks me for the password and gives me the result:

tomaz:~/ $ git ls-remote https://[e-mail]/tcanabrava/randrepo.git
Password: 
1c8cd7266ad19de952db096a0f25ee16dc3cdace        HEAD
1c8cd7266ad19de952db096a0f25ee16dc3cdace        refs/heads/master

but when I issue git clone...

tomaz:~/ $ $git clone https://[e-mail]/tcanabrava/randrepo.git
Cloning into 'felipao'...
Password: 
error: RPC failed; result=22, HTTP code = 401
fatal: The remote end hung up unexpectedly

And I'v already looked over and over on all google answers for this particular error and nothing could fix it.

1. I'm sure that the address is correct, it lists the branches using ls-remote.
2. already set the postBuffer = 52428800
3. the proxies are fine, it lists the branches using ls-remote
4. run with GIT_CURL_VERBOSE=1 too long to post here unfortunately =(

Answer 1

I had similiar problem. I'm not sure what helped, but:

1. I downgraded Curl to 7.25
2. I changed URL format with .netrc (http://stackoverflow.com/questions/5796171/git-clone-over-https-401-error-and-not-asking-for-username-or-password/5810821#5810821)
3. Everything is under git 1.7.10. I downgraded from 1.8.0-1 (pull and clone over WebDav just doesn't work in this version. As far as repos created with 1.7 are concerned. If someone know why, please write in a comment).

Answer 2

These are exact symptomps of a curl 7.28 bug. If you are using curl 7.28 downgrade it or switch to SSH auth until the fix comes out.

More info:

• http://sourceforge.net/tracker/?func=detail&atid=100976&aid=3577557&group_id=976
• http://curl.haxx.se/mail/tracker-2012-10/0014.html
• https://bugs.archlinux.org/task/32004

Answer 3

With Git 2.18 (Q2 2018), you now have more control over curl as used by Git.

The HTTP client code used to advertise that Git accept gzip encoding from the other side; instead, just let cURL library to advertise and negotiate the best one.

See commit eaf6a1b, commit 1a53e69 (22 May 2018) by Brandon Williams (mbrandonw).
^{(Merged by Junio C Hamano -- gitster -- in commit 13e8be9, 30 May 2018)}

remote-curl: accept all encodings supported by curl

Configure curl to accept all encodings which curl supports instead of only accepting gzip responses.

This fixes an issue when using an installation of curl which is built without the "zlib" feature. Since aa90b96 (Enable info/refs gzip decompression in HTTP client, 2012-09-19, Git 1.7.12.3) we end up requesting "gzip" encoding anyway despite libcurl not being able to decode it.
Worse, instead of getting a clear error message indicating so, we end up falling back to "dumb" http, producing a confusing and difficult to debug result.

Since curl doesn't do any checking to verify that it supports the a requested encoding, instead set the curl option CURLOPT_ENCODING with an empty string indicating that curl should send an "Accept-Encoding" header containing only the encodings supported by curl.