On Sat, Mar 23, 2019 at 04:53:41AM -0400, Jeff King wrote: > 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. Here's the patch, forward-ported on top of the current master, with actual commit messages, a test, and a few subtle tweaks around the curl_errorstr handling. [1/3]: http: factor out curl result code normalization [2/3]: http: normalize curl results for dumb loose and alternates fetches [3/3]: http: use normalize_curl_result() instead of manual conversion http-walker.c | 21 ++++++++++----------- http.c | 18 ++++++++++++------ http.h | 9 +++++++++ t/t5550-http-fetch-dumb.sh | 16 ++++++++++++++++ 4 files changed, 47 insertions(+), 17 deletions(-)
