On Thu, May 12, 2022 at 1:30 AM Christian Couder
[off-list ref] wrote:

On Tue, May 10, 2022 at 8:20 PM Carlo Arenas [off-list ref] wrote:

quoted

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"

quoted

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.

quoted

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