RE: [PATCH v2] config: introduce an Operating System-specific `includeIf` condition

[<rsbecker@nexbridge.com>]

On Wednesday, April 19, 2023 8:23 AM, Johannes Schindelin wrote:
>On Mon, 17 Apr 2023, Junio C Hamano wrote:
>
>> Samuel Ferencik <sferencik@gmail.com> writes:
>>
>> >>>> Let's introduce a new condition: `os:<uname-s>` where `<uname-s>`
>> >>>> is the system name, i.e. the output of `uname -s`.
>> >
>> > The discussion about https://github.com/gitgitgadget/git/pull/1429
>> > seems to have stalled on several points. I'll try to summarise;
>> > let's see if we can move forward.
>> >
>> > (I am the reporter of
>> > https://github.com/git-for-windows/git/issues/4125, which led to
>> > this PR. I am vested in making progress here.)
>> >
>> > 1. name of the setting (`os` vs `uname-s` vs `sysname`)
>>
>> I do not think it is a good idea to squat on too generic a name like
>> 'os', especially when there are multiple layers people will care
>> about.  But I think the original thread discussed this to death, and I
>> do not see a point bringing it up again as the first bullet point.
>
>Given what you said about "Operating System", i.e. that both "Ubuntu" and
"Linux"
>should be able to match at the same time, I kind of concur, but in the
other direction:
>rather than forcing the current patch series to use a less intuitive (i.e.
user-
>unfriendlier) name than `os`, I would want to modify the patch series so
that it _can_
>match "Ubuntu" and "Linux".
>
>> > 2. casing (use of `/i`)
>>
>> My preference is to do this case sensitively (in other words, start
>> stupid) and if somebody wants to use "/i", add it later after the dust
>> settles.
>
>I strongly disagree with this. This feature is meant for Git users, who I
must assume
>based on my experience would expect the value to be case-insensitive. I.e.
they
>would expect both `linux` and `Linux` to match. Let's not make this feature
harder to
>use than necessary!
>
>> > 3. handling Windows (MinGW, WSL)
>>
>> This comes back to the reason why "os" is a horrible choice.  Is WSL a
>> Windows?  Is WSL a Linux?  The same question can be asked for Cygwin.
>
>These questions actually have pretty obvious answers, with the exception of
WSL1
>(which nobody should use anymore): WSL is a Linux, Cygwin is not an
Operating
>System by itself but runs on Windows. But of course that's not helpful to
help
>configure Git specifically in a Cygwin setup.
>
>> The answer depends on which layer you care about.
>
>Yes, this is the crucial bit.
>
>> The underlying kernel and system may be Windows, and some
>> characteristics of the underlying system may seep through the
>> abstraction, but these systems aim to give user experience of
>> something like GNU/Linux.
>>
>> And this is not limited to Windows.  There may be similar issue for
>> systems like PacBSD.  Is it a Linux?  Is it a BSD?
>>
>> > 6. what's the use-case?
>>
>> I think that this is the most important question to ask, and from
>> here, we'd see how #3 above should be resolved (I suspect that you may
>> want to have at least two layers to allow WSL to be grouped together
>> with MinGW and Cygwin at one level, and at the same time allow it to
>> be grouped together with Ubuntu at a different level).
>> And after we figure that out, we'll have a clear and intuitive answer
>> to #1.
>
>This is probably the most valuable feedback in this entire thread: What is
the problem
>we're trying to solve here?
>
>The original report (which this patch tries to address) asks for a way to
have a user-
>wide ("global") Git configuration that can be shared across machines and
that allows
>for adapting to the various environments. The rationale is motivated well
e.g. in
>https://medium.com/doing-things-right/platform-specific-gitconfigs-and-the-
>wonderful-includeif-7376cd44994d
>where platform-specific credential managers, editors, diff highlighters
that work only
>in certain setups, and work vs personal environments are mentioned.
>
>So as long as Git offers ways to discern between the mentioned environments
by
>including environment-specific configuration files, we solve the problem.

I would suggest using match of uname arguments. But there are variants. The
OS release should also be included here as something like NONSTOP_KERNEL is
not a sufficient answer. We should have at the very least, or encode the
includeif string accordingly:

uname -r = the release n (e.g., J06)
uname -n = the node name (e.g., hpitug)
uname -s = the OS (e.g., NONSTOP_KERNEL

We use these in config.mak.uname (except for -n).

Regards,
Randall