[resending my previous response, which I had sent only to the PR, not the mailing list; composed before dscho@'s last email] > > 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. Fantastic. > > 6. what's the use-case? > > * Note all of the use-cases above would cope with WSL reporting "Linux", > > except of `merge.tool`. > > 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). Actually, I take that back: I can install the Linux version of BeyondCompare into WSL, use my license, and I'm fine with WSL reporting that it's Linux. (This is just to correct my previous claim. More below.) > > 3. handling Windows (MinGW, WSL) > > 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. Fair point. I think we only care about the top-most layer (the one nearest to the user). The "seeping through" aspect means things often aren't clear-cut, but I also think we can make practical decisions. The closer the top layer approximates an OS, the more we can say it *is* that OS without compromising correctness. For example, a Linux container on Windows should report (uname) it's a Linux, and `includeIf` should go by this. So should WSL2, I think, because it provides a Linux kernel. Maybe there is a use-case for git config (`includeIf`) to behave differently in WSL because the host OS is Windows, but I'm not aware of such a use-case. In contrast, "Git bash" and Cygwin report something other than "Linux" (`MINGW64_NT-<version>`, `CYGWIN_NT-<version>`) because they are not Linuxes, and that's also fine. Interestingly, though, they don't report the host OS (Windows) either. So I propose that we limit ourselves to the top-most layer. Can we come up with a name (`os` or another) that would capture this concept? - Felipe proposed `platform`. I'm afraid this may be confused with the hardware platform (as reported by `uname -m`). - Phillip proposed `uname-s`. It's self-documenting in a way, but it's also wrong on Windows and describes the tool rather than the concept. - Philip proposed `sysname`. It's slightly better but still very much a pointer to `utsname.sysname`. - dscho@ proposed `os`. I like it for its obviousness. The issues with the name are marginal (not bigger than with any other name) and can be sufficiently addressed by good documentation. If we can agree on the name, I can help fix up the documentation, the tests, and remove the case insensitivity. Thoughts?
