list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <>
To: Carlo Arenas <>
Cc: git <>, Junio C Hamano <>,
	Christian Couder <>,
	Derrick Stolee <>
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: <> (raw)
In-Reply-To: <>

On Tue, May 10, 2022 at 8:20 PM Carlo Arenas <> wrote:
> On Mon, May 9, 2022 at 8:38 AM Christian Couder
> <> wrote:
> > diff --git a/t/ b/t/
> > index f92c79c132..4a8dbb7eee 100755
> > --- a/t/
> > +++ b/t/
> > @@ -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' '
> > + &&
> > +       test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null &&
> > +       git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:" 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 left intact
== Info: RESOLVE is - old addresses discarded!
== Info: Added to DNS cache
== Info: Couldn't find host in the .netrc
file; using defaults
== Info: Found bundle for host 0x5556d2bd1340
== Info: Can not multiplex, even if we wanted to!
== Info: Re-using existing connection! (#0) with host
== Info: Connected to ( 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 ;-)

  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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \
    --subject='Re: [PATCH v3] http: add custom hostname to IP address resolutions' \

* 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:

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).