On 19/3/24 21:55, Eric Sunshine wrote: > 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/ Sorry if it sounded like I disregarded the opinion. I did see it and liked the idea, but I guessed something like that would face a lot of resistance. My bad. >> 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). Lets find this a good "home" then [1]. Thanks! [1] https://lore.kernel.org/git/CAPig+cTFRAmzBGiJv2F-k1XWvGSbT8UeAG57T+XpB-1w66HRkQ@xxxxxxxxxxxxxx/
