On Fri, Mar 22, 2019 at 04:50:34PM +0000, Eric Wong wrote:

quoted

Weird. I had set http.maxrequests to "1" to give more readable output
from GIT_CURL_VERBOSE, etc. It fails with that setting, but not with the
default of 5. Which certainly seems like a bug, but one that has been
there for a while (at least since v2.9.x, which I tested).

I couldn't reproduce an error after porting your patch to
master (commit 041f5ea1cf987a40 "The third batch"):
https://80x24.org/spew/20190322163449.25362-1-e@80x24.org/raw

So you might've hit an ephemeral error (bad connection,
HTTP server restarting, etc).

No, it was quite reproducible. Curious, I decided to bisect. The problem
started in ad75ebe5b3 (http: maintain curl sessions, 2009-11-27), but
was later fixed by your 2abc848d54 (http: always remove curl easy from
curlm session on release, 2016-09-13).

So trying to build the fix directly on 17966c0a63d (which is in between
those) will run into this unrelated bug. But forward-porting does work.

-Peff