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. > 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. > 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. The answer depends on which layer you care about. 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.
