From: Christian Couder <firstname.lastname@example.org> To: Carlo Arenas <email@example.com> Cc: git <firstname.lastname@example.org>, Junio C Hamano <email@example.com>, Christian Couder <firstname.lastname@example.org>, Derrick Stolee <email@example.com> Subject: Re: [PATCH v3] http: add custom hostname to IP address resolutions Date: Thu, 12 May 2022 10:29:59 +0200 [thread overview] Message-ID: <CAP8UFD2F=5RsB_WVOHKmzJsD9UJgZ2YM_yreTur2_huAAJ=+Vw@mail.gmail.com> (raw) In-Reply-To: <CAPUEsphA=q10wCsrf3AxR9fXz9HQHt374tDFoWBu++EPNDA-LA@mail.gmail.com> On Tue, May 10, 2022 at 8:20 PM Carlo Arenas <firstname.lastname@example.org> wrote: > > On Mon, May 9, 2022 at 8:38 AM Christian Couder > <email@example.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 ;-)
next prev parent reply other threads:[~2022-05-12 8:31 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-02 8:36 [PATCH] http: add custom hostname to IP address resolves Christian Couder 2022-05-02 19:04 ` Junio C Hamano 2022-05-04 10:07 ` Christian Couder 2022-05-04 14:34 ` Junio C Hamano 2022-05-05 10:48 ` Christian Couder 2022-05-05 11:16 ` Carlo Marcelo Arenas Belón 2022-05-09 15:40 ` Christian Couder 2022-05-04 10:46 ` [PATCH v2] http: add custom hostname to IP address resolutions Christian Couder 2022-05-05 11:21 ` Carlo Marcelo Arenas Belón 2022-05-12 8:52 ` Christian Couder 2022-05-12 16:22 ` Junio C Hamano 2022-05-12 18:57 ` Christian Couder 2022-05-09 15:38 ` [PATCH v3] " Christian Couder 2022-05-10 18:20 ` Carlo Arenas 2022-05-12 8:29 ` Christian Couder [this message] 2022-05-12 11:55 ` Carlo Arenas 2022-05-12 13:01 ` Patrick Steinhardt 2022-05-12 13:56 ` Carlo Arenas 2022-05-12 15:58 ` Junio C Hamano 2022-05-16 8:38 ` [PATCH v4] " Christian Couder
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAP8UFD2F=5RsB_WVOHKmzJsD9UJgZ2YM_yreTur2_huAAJ=+Vw@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v3] http: add custom hostname to IP address resolutions' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).