Junio C Hamano <gitster@xxxxxxxxx> writes: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > >> This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7. >> >> Retrying without the query parameter was added as a workaround >> for a single broken HTTP server at git.debian.org[1]. The server >> was misconfigured to route every request with a query parameter >> into gitweb.cgi. Admins fixed the server's configuration within >> 16 hours of the bug report to the Git mailing list, but we still >> patched Git with this fallback and have been paying for it since. > > As the consequence of the above, the only two things we know about > the servers in the wild are (1) a misconfiguration that requires > this retry was once made, so it is not very unlikely others did the > same misconfiguration, and (2) those unknown number of servers have > been happily serving the current clients because the workaround > patch have been hiding the misconfiguration ever since. > > But as long as the failure diagnosis from updated clients that > revert this workaround is sufficient to allow such misconfigured > servers, I think it is OK. We might see a large number of small s/servers,/servers diagnosed,/; > people having to run around and fix the configuration as a fallout, > though. > >> Most Git hosting services configure the smart HTTP protocol and the >> retry logic confuses users when there is a transient HTTP error as >> Git dropped the real error from the smart HTTP request. Removing the >> retry makes root causes easier to identify. > > Does that hold true also for dumb only small people installations? > They are the ones that need more help than the large installations > staffed sufficiently and run smart http gateway. In any case, will queue. -- 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