On Sun, Feb 14, 2016 at 8:50 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Feb 13, 2016 at 05:39:34PM -0800, Shawn Pearce wrote: > >> For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the >> additional text stored in CURLOPT_ERRORBUFFER to debug why >> the connection did not start. This is curl_errorstr inside >> of http.c, so include that in the message if it is non-empty. > > I think this is an all-around improvement. GitHub sometimes get support > requests for result=18 on a git-push, which is curl's code for "I dunno, > the remote end hung up". Having a human-readable message may make things > less confusing. I have been trying to recreate the error 35 scenario, but after almost a day of continuous attempts with a suspected broken Git I thus far have not been able to reproduce it. *sigh* What made me pick this up was I got another recent report of a Debian system having trouble connecting to $DAY_JOB's HTTPS server, which reminded me of [2]. I was going to revive that patch, but instead decided to expand on the error reporting. [2] http://article.gmane.org/gmane.comp.version-control.git/206770 > Unfortunately I cannot seem to create the problem at will to confirm > that it kicks in in this case[1], but it seems like it should just based on > reading your patch. > > -Peff > > [1] I tried inserting "exit(0)" in various places of receive-pack, and > it seems make the protocol deadlock. Yikes. This actually doesn't surprise me. *sigh* With all the pipes and libcurl in there, we must somewhere be ignoring the fact that the HTTP server closed the connection. -- 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