Re: [PATCH v3 0/2] Add hostname condition to includeIf
On 19/3/24 21:55, Eric Sunshine wrote:
Show 16 quoted lines
> On Tue, Mar 19, 2024 at 2:38 PM Ignacio Encinas <ignacio@iencinas.com> 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@coredump.intra.peff.net/
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.
Show 26 quoted lines
>> 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@mail.gmail.com/