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