| Message ID | 20220509153834.485871-1-chriscool@tuxfamily.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v3] http: add custom hostname to IP address resolutions | expand |
On Mon, May 9, 2022 at 8:38 AM Christian Couder <christian.couder@gmail.com> wrote: > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh > index f92c79c132..4a8dbb7eee 100755 > --- a/t/t5551-http-fetch-smart.sh > +++ b/t/t5551-http-fetch-smart.sh > @@ -567,4 +567,11 @@ test_expect_success 'client falls back from v2 to v0 to match server' ' > grep symref=HEAD:refs/heads/ trace > ' > > +test_expect_success 'passing hostname resolution information works' ' > + BOGUS_HOST=gitbogusexamplehost.com && > + BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT && > + test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null && > + git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null > +' Is setting it up as a command line config option the way you expect to use this, and if so why not make it a full blown command line option with the previous caveats that were discussed before? I also think it might be a little confusing (and probably warranted of an advice message) if git will decide based on a configuration somewhere in its resolution tree that the IP I am connecting is different than the one I expect it to use through the system configured resolution mechanism for such a thing. I assume that if you want to use this frequently, having that advice disabled in your global config wouldn't be a hassle, but it might be useful to know that I am interacting with a potentially different IP when referring to some host by name in my local repo, maybe because I forgot to change that setting after some debugging. I am sure all those folks that forget to edit their /etc/hosts after they are done with their local site versions might instead use this and then be happy to be warned about it later. Carlo
On Tue, May 10, 2022 at 8:20 PM Carlo Arenas <carenas@gmail.com> wrote: > > On Mon, May 9, 2022 at 8:38 AM Christian Couder > <christian.couder@gmail.com> wrote: > > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh > > index f92c79c132..4a8dbb7eee 100755 > > --- a/t/t5551-http-fetch-smart.sh > > +++ b/t/t5551-http-fetch-smart.sh > > @@ -567,4 +567,11 @@ test_expect_success 'client falls back from v2 to v0 to match server' ' > > grep symref=HEAD:refs/heads/ trace > > ' > > > > +test_expect_success 'passing hostname resolution information works' ' > > + BOGUS_HOST=gitbogusexamplehost.com && > > + BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT && > > + test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null && > > + git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null > > +' > > Is setting it up as a command line config option the way you expect to > use this, and if so why not make it a full blown command line option > with the previous caveats that were discussed before? Yeah, it's how GitLab will likely use this, but this is the same for most (if not all) config options these days in GitLab. So I don't think it's a good criteria. I already talked about it, but one of the issues with a command line option is that such an option might not be worth implementing for SSH (which might not need it) or other protocols for different reasons. So we would have a CLI option with probably a generic name that would actually work only with one (or a few) protocols, and we would need to decide what to do in case this option is used along with a protocol that it doesn't support. > I also think it might be a little confusing (and probably warranted of > an advice message) if git will decide based on a configuration > somewhere in its resolution tree that the IP I am connecting is > different than the one I expect it to use through the system > configured resolution mechanism for such a thing. I would be Ok to add an advice message or another kind of message telling users that the IP used is based on the config variable. It could break scripts parsing Git's output though (even if it's bad practice to do so). So we would need to decide the kind of message and its content. Suggestions welcome. > I assume that if you want to use this frequently, having that advice > disabled in your global config wouldn't be a hassle, but it might be > useful to know that I am interacting with a potentially different IP > when referring to some host by name in my local repo, maybe because I > forgot to change that setting after some debugging. Yeah, maybe. On the other hand GIT_CURL_VERBOSE might already be the canonical way to debug this and might already tell about this. Yeah, it does: <= Recv header: == Info: Connection #0 to host gitbogusexamplehost.com left intact == Info: RESOLVE gitbogusexamplehost.com:5551 is - old addresses discarded! == Info: Added gitbogusexamplehost.com:5551:127.0.0.1 to DNS cache == Info: Couldn't find host gitbogusexamplehost.com in the .netrc file; using defaults == Info: Found bundle for host gitbogusexamplehost.com: 0x5556d2bd1340 [serially] == Info: Can not multiplex, even if we wanted to! == Info: Re-using existing connection! (#0) with host gitbogusexamplehost.com == Info: Connected to gitbogusexamplehost.com (127.0.0.1) port 5551 (#0) I agree it might not be very clear that it's because "http.curloptResolve" is used though. But maybe we could output a more explicit warning message only if GIT_CURL_VERBOSE is set. > I am sure all those folks that forget to edit their /etc/hosts after > they are done with their local site versions might instead use this > and then be happy to be warned about it later. Do you mean that those folks might like a config option ;-)
On Thu, May 12, 2022 at 1:30 AM Christian Couder <christian.couder@gmail.com> wrote: > On Tue, May 10, 2022 at 8:20 PM Carlo Arenas <carenas@gmail.com> wrote: > > I also think it might be a little confusing (and probably warranted of > > an advice message) if git will decide based on a configuration > > somewhere in its resolution tree that the IP I am connecting is > > different than the one I expect it to use through the system > > configured resolution mechanism for such a thing. > > I would be Ok to add an advice message or another kind of message > telling users that the IP used is based on the config variable. It > could break scripts parsing Git's output though (even if it's bad > practice to do so). Only if they added that config option, which is an obscure one that nobody should be using anyway, so very unlikely, right? I also think that breaking my script could be avoided by turning off the advice (as suggested previously), and I MIGHT want to have my script broken if I picked up this config by mistake. > So we would need to decide the kind of message and > its content. Suggestions welcome. I am not good at wording those, but I would think something innocuous like : "curl override detected to point name %s to %s instead of using DNS" > > I assume that if you want to use this frequently, having that advice > > disabled in your global config wouldn't be a hassle, but it might be > > useful to know that I am interacting with a potentially different IP > > when referring to some host by name in my local repo, maybe because I > > forgot to change that setting after some debugging. > > Yeah, maybe. On the other hand GIT_CURL_VERBOSE might already be the > canonical way to debug this and might already tell about this. of course, but that is mostly used when debugging HTTP issues, not when your DNS seems to have gone nuts, and you are looking at your screen in disbelief because the code you were working on before lunch and having released is now suddenly in production. > Yeah, it does: > > <= Recv header: > == Info: Connection #0 to host gitbogusexamplehost.com left intact > == Info: RESOLVE gitbogusexamplehost.com:5551 is - old addresses discarded! > == Info: Added gitbogusexamplehost.com:5551:127.0.0.1 to DNS cache > == Info: Couldn't find host gitbogusexamplehost.com in the .netrc > file; using defaults > == Info: Found bundle for host gitbogusexamplehost.com: 0x5556d2bd1340 > [serially] > == Info: Can not multiplex, even if we wanted to! > == Info: Re-using existing connection! (#0) with host gitbogusexamplehost.com > == Info: Connected to gitbogusexamplehost.com (127.0.0.1) port 5551 (#0) > > I agree it might not be very clear that it's because > "http.curloptResolve" is used though. But maybe we could output a more > explicit warning message only if GIT_CURL_VERBOSE is set. As I pointed in my example I can see this being useful also for some web developing which are mostly concerned about JavaScript and might not be aware of the OSI layer stack and how to get an HTTP packet dump, so I would think better done even when GIT_CURL_VERBOSE is not set. > > I am sure all those folks that forget to edit their /etc/hosts after > > they are done with their local site versions might instead use this > > and then be happy to be warned about it later. > > Do you mean that those folks might like a config option ;-) Yes, and I think it is not THAT of an obscure config option if it even has documentation as well ;) Carlo
On Tue, May 10, 2022 at 11:20:41AM -0700, Carlo Arenas wrote: > On Mon, May 9, 2022 at 8:38 AM Christian Couder > <christian.couder@gmail.com> wrote: > > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh > > index f92c79c132..4a8dbb7eee 100755 > > --- a/t/t5551-http-fetch-smart.sh > > +++ b/t/t5551-http-fetch-smart.sh > > @@ -567,4 +567,11 @@ test_expect_success 'client falls back from v2 to v0 to match server' ' > > grep symref=HEAD:refs/heads/ trace > > ' > > > > +test_expect_success 'passing hostname resolution information works' ' > > + BOGUS_HOST=gitbogusexamplehost.com && > > + BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT && > > + test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null && > > + git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null > > +' > > Is setting it up as a command line config option the way you expect to > use this, and if so why not make it a full blown command line option > with the previous caveats that were discussed before? If you did this as a command-line option, you'd now be forced to add it to every single command you want to support this: git-fetch, git-pull, git-remote, git-ls-remote and maybe others I forgot about. On the other hand, by having this as a configuration variable in `http.c` all of those commands benefit the same. Furthermore, using a config option is a lot more flexible: you can persist it at different levels of your gitconfig, can easily inject it in a script via the use of environment variables, or directly override it when spawning a command with `-c`. Overall, I think it is preferable to keep this as an option as opposed to adding such an obscure parameter to all of the commands. > I also think it might be a little confusing (and probably warranted of > an advice message) if git will decide based on a configuration > somewhere in its resolution tree that the IP I am connecting is > different than the one I expect it to use through the system > configured resolution mechanism for such a thing. That's true already though, isn't it? A user may set `url.*.insteadOf` and be surprised at a later point that their URLs are getting redirected somewhere else. And there's probably a lot more examples where a user may be confused when forgetting about certain configuration variables that change the way Git behaves. I also don't think that using an advise here would be ideal. The main use case of this configuration variable is going to be servers, and there is a high chance that they might actually be parsing output of any such commands. Forcing them to always disable this advise doesn't feel like the right thing to do. Patrick > I assume that if you want to use this frequently, having that advice > disabled in your global config wouldn't be a hassle, but it might be > useful to know that I am interacting with a potentially different IP > when referring to some host by name in my local repo, maybe because I > forgot to change that setting after some debugging. > > I am sure all those folks that forget to edit their /etc/hosts after > they are done with their local site versions might instead use this > and then be happy to be warned about it later. > > Carlo
On thu, May 12, 2022 at 6:01 AM Patrick Steinhardt <ps@pks.im> wrote: > On Tue, May 10, 2022 at 11:20:41AM -0700, Carlo Arenas wrote: > > On Mon, May 9, 2022 at 8:38 AM Christian Couder > > <christian.couder@gmail.com> wrote: > > > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh > > > index f92c79c132..4a8dbb7eee 100755 > > > --- a/t/t5551-http-fetch-smart.sh > > > +++ b/t/t5551-http-fetch-smart.sh > > > @@ -567,4 +567,11 @@ test_expect_success 'client falls back from v2 to v0 to match server' ' > > > grep symref=HEAD:refs/heads/ trace > > > ' > > > > > > +test_expect_success 'passing hostname resolution information works' ' > > > + BOGUS_HOST=gitbogusexamplehost.com && > > > + BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT && > > > + test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null && > > > + git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null > > > +' > > > > Is setting it up as a command line config option the way you expect to > > use this, and if so why not make it a full blown command line option > > with the previous caveats that were discussed before? > > If you did this as a command-line option, you'd now be forced to add it > to every single command you want to support this: git-fetch, git-pull, > git-remote, git-ls-remote and maybe others I forgot about. On the other > hand, by having this as a configuration variable in `http.c` all of > those commands benefit the same. There are ways to add common options to all commands that would help here, but as Junio pointed out it is not ideal because then you have to ALSO provide implementations, which you don't seem interested in doing. > Furthermore, using a config option is a lot more flexible: you can > persist it at different levels of your gitconfig, can easily inject it > in a script via the use of environment variables, or directly override > it when spawning a command with `-c`. > > Overall, I think it is preferable to keep this as an option as opposed > to adding such an obscure parameter to all of the commands. I think we had already decided that a config is more flexible, even if I personally don't agree. > > I also think it might be a little confusing (and probably warranted of > > an advice message) if git will decide based on a configuration > > somewhere in its resolution tree that the IP I am connecting is > > different than the one I expect it to use through the system > > configured resolution mechanism for such a thing. > > That's true already though, isn't it? A user may set `url.*.insteadOf` > and be surprised at a later point that their URLs are getting redirected > somewhere else. And there's probably a lot more examples where a user > may be confused when forgetting about certain configuration variables > that change the way Git behaves. That is a good point, but unlike url.*.insteadOf, this is meant to be an obscure setting that shouldn't be enabled by default (or under common circumstances), so having the advice there is helpful for when we find ourselves in an unexpected situation and to avoid confusion. I would even argue YOUR use of it in a server might even benefit from this advice, because it could be strange to get a different IP than the one you set in the command line if there is also another entry in some config that you happened to read. > I also don't think that using an advise here would be ideal. The main > use case of this configuration variable is going to be servers. My feedback about servers is indeed below, so I won't repeat myself but keeping a global config that has this advice disabled in a server shouldn't be that difficult; indeed it MIGHT be already there since most features that are meant for interactive users (like an advice) are better disabled in servers. > > I assume that if you want to use this frequently, having that advice > > disabled in your global config wouldn't be a hassle, but it might be > > useful to know that I am interacting with a potentially different IP > > when referring to some host by name in my local repo, maybe because I > > forgot to change that setting after some debugging. > > > > I am sure all those folks that forget to edit their /etc/hosts after > > they are done with their local site versions might instead use this > > and then be happy to be warned about it later. > > > > Carlo
Patrick Steinhardt <ps@pks.im> writes: >> Is setting it up as a command line config option the way you expect to >> use this, and if so why not make it a full blown command line option >> with the previous caveats that were discussed before? > > If you did this as a command-line option, you'd now be forced to add it > to every single command you want to support this: git-fetch, git-pull, > git-remote, git-ls-remote and maybe others I forgot about. On the other > hand, by having this as a configuration variable in `http.c` all of > those commands benefit the same. It is not an argument against the command line option that you find it more work to implement and cumbersome to plumb the information through the callgraph, though. Subcommands like "git commit" shouldn't have to know how host names are mapped to IP addresses, and teaching the option only to subcommands that the feature is relevant, and documenting the option in their manual pages, would make it much easier to discover and learn. > Overall, I think it is preferable to keep this as an option as opposed > to adding such an obscure parameter to all of the commands. I favor implementing this as a configuration that is primarily meant to be used from the command line (i.e. "git -c var=val"), ONLY BECAUSE the feature itself is not something that should be widely used (the users should futz with their DNS if they need something more permanent), and adding it as a configuration would be a more quick and dirty way that needs less developer resources now ;-) To purists, it may make more sense to add this feature and make it accessible only from the command line without matching configuration variable---that would enforce the assumed use case (i.e. only after another part of the system asked DNS, performed some check on the resulting IP address, and decided to ask Git to interact with that URL, use this mechanism to ensure Git interacts with that IP address that was vetted, to avoid TOCTOU mistakes) more clearly. I am personally open to such a purer counterproposal with working code ;-) >> I also think it might be a little confusing (and probably warranted of >> an advice message) if git will decide based on a configuration >> somewhere in its resolution tree that the IP I am connecting is >> different than the one I expect it to use through the system >> configured resolution mechanism for such a thing. > > That's true already though, isn't it? A user may set `url.*.insteadOf` > and be surprised at a later point that their URLs are getting redirected > somewhere else. And there's probably a lot more examples where a user > may be confused when forgetting about certain configuration variables > that change the way Git behaves. > > I also don't think that using an advise here would be ideal. The main > use case of this configuration variable is going to be servers, and > there is a high chance that they might actually be parsing output of any > such commands. Forcing them to always disable this advise doesn't feel > like the right thing to do. All correct. If the users set configuration variables, the fact that we honored their configuration variables settings and behaved accordingly is *NOT* an advise-worthy event. Thanks.
diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt index 7003661c0d..179d03e57b 100644 --- a/Documentation/config/http.txt +++ b/Documentation/config/http.txt @@ -98,6 +98,22 @@ http.version:: - HTTP/2 - HTTP/1.1 +http.curloptResolve:: + Hostname resolution information that will be used first by + libcurl when sending HTTP requests. This information should + be in one of the following formats: + + - [+]HOST:PORT:ADDRESS[,ADDRESS] + - -HOST:PORT + ++ +The first format redirects all requests to the given `HOST:PORT` +to the provided `ADDRESS`(s). The second format clears all +previous config values for that `HOST:PORT` combination. To +allow easy overriding of all the settings inherited from the +system config, an empty value will reset all resolution +information to the empty list. + http.sslVersion:: The SSL version to use when negotiating an SSL connection, if you want to force the default. The available and default version diff --git a/http.c b/http.c index 229da4d148..8beacb95cc 100644 --- a/http.c +++ b/http.c @@ -128,6 +128,8 @@ static struct curl_slist *pragma_header; static struct curl_slist *no_pragma_header; static struct string_list extra_http_headers = STRING_LIST_INIT_DUP; +static struct curl_slist *host_resolutions; + static struct active_request_slot *active_queue_head; static char *cached_accept_language; @@ -393,6 +395,18 @@ static int http_options(const char *var, const char *value, void *cb) return 0; } + if (!strcmp("http.curloptresolve", var)) { + if (!value) { + return config_error_nonbool(var); + } else if (!*value) { + curl_slist_free_all(host_resolutions); + host_resolutions = NULL; + } else { + host_resolutions = curl_slist_append(host_resolutions, value); + } + return 0; + } + if (!strcmp("http.followredirects", var)) { if (value && !strcmp(value, "initial")) http_follow_config = HTTP_FOLLOW_INITIAL; @@ -1131,6 +1145,9 @@ void http_cleanup(void) curl_slist_free_all(no_pragma_header); no_pragma_header = NULL; + curl_slist_free_all(host_resolutions); + host_resolutions = NULL; + if (curl_http_proxy) { free((void *)curl_http_proxy); curl_http_proxy = NULL; @@ -1211,6 +1228,7 @@ struct active_request_slot *get_active_slot(void) if (curl_save_cookies) curl_easy_setopt(slot->curl, CURLOPT_COOKIEJAR, curl_cookie_file); curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header); + curl_easy_setopt(slot->curl, CURLOPT_RESOLVE, host_resolutions); curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr); curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL); curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, NULL); diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index f92c79c132..4a8dbb7eee 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -567,4 +567,11 @@ test_expect_success 'client falls back from v2 to v0 to match server' ' grep symref=HEAD:refs/heads/ trace ' +test_expect_success 'passing hostname resolution information works' ' + BOGUS_HOST=gitbogusexamplehost.com && + BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT && + test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null && + git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null +' + test_done
Libcurl has a CURLOPT_RESOLVE easy option that allows the result of hostname resolution in the following format to be passed: [+]HOST:PORT:ADDRESS[,ADDRESS] This way, redirects and everything operating against the HOST+PORT will use the provided ADDRESS(s). The following format is also allowed to stop using hostname resolutions that have already been passed: -HOST:PORT See https://curl.se/libcurl/c/CURLOPT_RESOLVE.html for more details. Let's add a corresponding "http.curloptResolve" config option that takes advantage of CURLOPT_RESOLVE. Each value configured for the "http.curloptResolve" key is passed "as is" to libcurl through CURLOPT_RESOLVE, so it should be in one of the above 2 formats. This keeps the implementation simple and makes us consistent with libcurl's CURLOPT_RESOLVE, and with curl's corresponding `--resolve` command line option. The implementation uses CURLOPT_RESOLVE only in get_active_slot() which is called by all the HTTP request sending functions. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- Changes since v2 are the following: - option renamed from "http.resolve" to "http.curloptResolve" - mention "libcurl" instead of "curl" in the commit message - mention "libculr" in the doc to make it easier to understand the new option name Range diff: 1: 28c3bf9d02 ! 1: 3d689f8a6f http: add custom hostname to IP address resolutions @@ Commit message See https://curl.se/libcurl/c/CURLOPT_RESOLVE.html for more details. - Let's add a corresponding "http.resolve" config option - that takes advantage of CURLOPT_RESOLVE. + Let's add a corresponding "http.curloptResolve" config + option that takes advantage of CURLOPT_RESOLVE. - Each value configured for the "http.resolve" key is - passed "as is" to curl through CURLOPT_RESOLVE, so it - should be in one of the above 2 formats. This keeps the - implementation simple and makes us consistent with + Each value configured for the "http.curloptResolve" key + is passed "as is" to libcurl through CURLOPT_RESOLVE, so + it should be in one of the above 2 formats. This keeps + the implementation simple and makes us consistent with libcurl's CURLOPT_RESOLVE, and with curl's corresponding `--resolve` command line option. @@ Documentation/config/http.txt: http.version:: - HTTP/2 - HTTP/1.1 -+http.resolve:: -+ Hostname resolution information that will be used first when sending -+ HTTP requests. This information should be in one of the following -+ formats: ++http.curloptResolve:: ++ Hostname resolution information that will be used first by ++ libcurl when sending HTTP requests. This information should ++ be in one of the following formats: + + - [+]HOST:PORT:ADDRESS[,ADDRESS] + - -HOST:PORT @@ http.c: static int http_options(const char *var, const char *value, void *cb) return 0; } -+ if (!strcmp("http.resolve", var)) { ++ if (!strcmp("http.curloptresolve", var)) { + if (!value) { + return config_error_nonbool(var); + } else if (!*value) { @@ t/t5551-http-fetch-smart.sh: test_expect_success 'client falls back from v2 to v + BOGUS_HOST=gitbogusexamplehost.com && + BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT && + test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null && -+ git -c "http.resolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null ++ git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null +' + test_done Documentation/config/http.txt | 16 ++++++++++++++++ http.c | 18 ++++++++++++++++++ t/t5551-http-fetch-smart.sh | 7 +++++++ 3 files changed, 41 insertions(+)