On Saturday, March 16, 2024 1:03 PM, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

Do we need to define "hostname" in more detail here? Specifically, I'm
wondering whether the result will be a FQDN or not (i.e., the output
of "hostname" vs "hostname -f"). Looking at the code I think it will
just be the short name returned. That's probably OK, but it may be
worth documenting.

That was my first reaction but there are places where "hostname"
already gives a name that is not "short" at all, without being invoked with

"-f".

For example, the (virtual) workstation I am typing this message on sits in

a $WORK datacenter, where "hostname" gives the same

string as "hostname -f", which looks like "git.c.xxxxxx.tld" ("git" is the

only part I picked myself for it, "c" is shared by those employee

workstations hosted at datacenters, "xxxxxx.tld" is redacted to conceal the

real domain name to protect the culprits ;-).

I think the most honest answer we can give in the documentation is that we

use what gethostname() [*] gives.

I think this is probably a good idea and but value should not be cached. My
dev box has a multi-home, multi-cpu IP stack. It makes things really weird
sometimes. For example, hostname replies with:

ztc0.xxxxxxxx.local

and includes the current default IP stack, which is known to DNS, while
uname -n, which I prefer to use when deciding what system I am on during
tests, reports:

xxxxxxxx

I am not sure how meaningful hostname is; however, "hostname -f" is not
portable. However, includeif depending on whatever gethostname() returns is
reasonable, in my opinion, also. I think the series should include a $(uname
-n) option in some form for completeness.

[References]

*

https://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname.html

--Randall