On Fri, Mar 22, 2019 at 04:50:34PM +0000, Eric Wong wrote: > > 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@xxxxxxxxx/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
