On Wednesday, April 19, 2023 8:23 AM, Johannes Schindelin wrote: >On Mon, 17 Apr 2023, Junio C Hamano wrote: > >> Samuel Ferencik <sferencik@xxxxxxxxx> 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
