On Tuesday, March 19, 2024 6:27 PM, Dirk Gouders wrote: ><rsbecker@xxxxxxxxxxxxx> writes: > >> On Tuesday, March 19, 2024 5:37 PM, Dirk Gouders wrote: >>>Junio C Hamano <gitster@xxxxxxxxx> writes: >>> >>>> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: >>>> >>>>> Peff felt that adding `git config --show-hostname-for-includes` was >>>>> probably overkill, but I'd argue that it is necessary to enable >>>>> users to deterministically figure out the value to use in their >>>>> configuration rather than having to grope around in the dark via >>>>> guesswork and trial-and-error to figure out exactly what works. >>>>> >>>>> And the option name doesn't necessarily have to be so verbose; a >>>>> shorter name, such as `git config --show-hostname` may be good enough. >>>>> Implementing this option would also obviate the need to implement >>>>> `test-tool xgethostname` (though, I agree with Junio that >>>>> `test-tool gethostname` would have been a better, less >>>>> implementation-revealing name). >>>> >>>> Yeah, I like that show-hostname thing (which I do not know if "config" >>>> is a good home for, though). >>> >>>A thought when I was reading this: wouldn't it be enough to document >>>that >> `uname -n` can be used to get the hostname that should >>>be used? >>> >>>As far as I know this should be POSIX-compliant and uses gethostname(2). >> >> As previously pointed out, uname -n and gethostname(2) are not equivalent. >> uname -n does not (depending on implementation) go to DNS while >> gethostname(2) goes to DNS first (although apparently glibc may not). >> This is particularly important in a multi-home situation where more >> than one IP adapter has a different IP address on the same host, and >> where DNS does not consider the different addresses to be equivalent >> (which otherwise could cause problems for reverse lookups). > >Thanks for the explanation, I did not notice this has already been discussed. > >Interestingly, I strace(1)'ed uname -n here on Linux and noticed it uses >uname(2) (what else?) and not gethostname(2), so it seems I was completely >wrong. > >Sorry for disturbing the discussion. No worries. I only know this point because I was rather deeply in a related code base back in 1994. I did not know that glibc varied from an old UNIX (I think that's where the code was from) code base prior to this thread. Learning is good and never a problem. Regards, Randall