"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > From: "Shawn O. Pearce" <spearce@xxxxxxxxxxx> > > If the user doesn't want to use the dumb HTTP protocol, she may > set GIT_CURL_FALLBACK=0 in the environment before invoking a Git > protocol operation. This is mostly useful when testing against > servers that are known to not support the dumb protocol. If the > smart service detection fails the client should not continue with > dumb behavior, but instead provide accurate HTTP failure data. > > Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx> > --- > remote-curl.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) I can see how this feature may be useful, but I have to say the external interface triply sucks. - If it is primarily for debugging smart HTTP, a solution with an environment variable without more permanent configuration variable would be sufficient, but then the environment variable is better named GIT_SMART_HTTP_DEBUG, or something no? - If it is useful outside the context of debugging, perhaps a per remote configuration variable remote.$name.$variable (or http.$prefix_of_server_url.$variable) might be necessary? - I do not see this as "fallback (to) curl"; you still talk your smart protocol over curl library. "fallback to dumb http" is more understandable. In any case, I think CURL_FALLBACK was named with CURL in its name primarily because the environment applies only to remote-curl, but that means we cannot have any fallback logic other than the current "smart does not work, fall back on dumb" in the future. Here is a bit of rewrite. [1/2] is yours but with a bit more sensible name. [2/2] is entirely optional. Junio C Hamano (1): remote-curl: make dumb-http fallback configurable per URL Shawn O. Pearce (1): Disable dumb HTTP fallback with GIT_DUMB_HTTP_FALLBACK=false remote-curl.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 2 deletions(-) -- 1.7.12.1.389.g3dff30b -- 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