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:

quoted

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.

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(-)