On Tue, May 10, 2022 at 8:20 PM Carlo Arenas <carenas@xxxxxxxxx> wrote: > > On Mon, May 9, 2022 at 8:38 AM Christian Couder > <christian.couder@xxxxxxxxx> 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 ;-)
