On Sun, Apr 01, 2012 at 09:45:36PM +0200, Clemens Buchacher wrote: > So far I figured out that setting 'git config http.maxRequests 1' fixes > the problem as well. Looking at the output with GIT_CURL_VERBOSE=1 set, > it seems that some GET requests use the credentials, while others do > not. My guess is that the CURLOPT_USERPWD option does not apply to all > threads. Yes, that is exactly it. Furthermore, the multi-fetch code paths used by the http walker do not have the magic "notice a 401 and retry". I think something like this should fix it (it passes your tests): diff --git a/http.c b/http.c index f3f83d7..c6dc9b7 100644 --- a/http.c +++ b/http.c @@ -494,6 +494,8 @@ struct active_request_slot *get_active_slot(void) curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL); curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0); curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1); + if (http_auth.password) + init_curl_http_auth(slot->curl); return slot; } which is basically just double-checking that we set CURLOPT_USERPWD whenever we get a slot (I wish there was some way of asking "does this curl handle have USERPWD already set?", but I couldn't fine one). It still doesn't do 401-handling itself, but it works OK in practice because the first request will be a non-multi fetch (to get info/refs), which recognizes the 401 and prompts the user, and then that credential gets used subsequently. -Peff -- 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