On Tue, Mar 19, 2024 at 2:38 PM Ignacio Encinas <ignacio@xxxxxxxxxxxx> wrote: > It was pointed out that it wasn't particularly obvious what it was meant by > > "If the current hostname matches the pattern, the include condition is met." > > which is definitely true. Despite this, to my knowledge, there isn't a > way to precisely define what we mean by "hostname" other than saying > that we mean whatever is returned by gethostname(2). > > I still think the documentation isn't great, but I don't see a way to > improve it further. Peff provided the answer when he suggested[1] implementing `git config --show-hostname-for-includes`. [1]: https://lore.kernel.org/git/20240318081722.GA602575@xxxxxxxxxxxxxxxxxxxxxxx/ > 1: cf175154109e ! 2: dec622c38916 config: learn the "hostname:" includeIf condition > @@ Documentation/config.txt: As for the naming of this keyword, it is for forwards > +`hostname`:: > + The data that follows the keyword `hostname:` is taken to be a > + pattern with standard globbing wildcards. If the current > -+ hostname matches the pattern, the include condition is met. > ++ hostname (output of gethostname(2)) matches the > ++ pattern, the include condition is met. This is still unnecessarily user-hostile, especially to users who are not programmers, but also to programmers who don't want to waste time writing a little test program to determine what gethostname(2) returns on each platform they use. That's not a great situation. 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).
