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

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Apr 19, 2023, 15:21 UTC
Message-ID: <009c01d972d2$b2bd7680$18386380$@nexbridge.com>
In-Reply-To: <67a2d12c-6250-c4ee-dd26-fd8ecc71b8bc@gmx.de>

On Wednesday, April 19, 2023 8:23 AM, Johannes Schindelin wrote:

Show 23 quoted lines

>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_

Show 9 quoted lines

>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

Show 8 quoted lines

>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

Show 25 quoted lines

>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