git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
SFSamuel Ferencik <sferencik@gmail.com>
Date
Apr 19, 2023, 14:32 UTC
Message-ID
<CABwTEiSd1_WB_BXpT9BqkO3+rb2+FaZ7fFhGLo=CW=feKG2gUw@mail.gmail.com>
In-Reply-To
<CAPx1GvcsxFbdUBZayzAU0U1MNMUN2NqaBLfZ6C1M=SykWQ_CHg@mail.gmail.com>

[resending my previous response, which I had sent only to the PR, not the mailing list; composed before dscho@'s last email]

Show 5 quoted lines
> > 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?
Show 8 quoted lines
> > * 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.)

Show 6 quoted lines
> > 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?

Previous: Chris TorekNext: rsbecker@nexbridge.com
Message 22 of 26 in “config: introduce an Operating System-specific `includeIf` condition”
  1. config: introduce an Operating System-specific `includeIf` conditionJohannes Schindelin via GitGitGadget, Nov 21, 2022
  2. Ævar Arnfjörð BjarmasonNov 21, 2022
  3. Phillip WoodNov 21, 2022
  4. Johannes SchindelinNov 21, 2022
  5. config: introduce an Operating System-specific `includeIf` conditionJohannes Schindelin via GitGitGadget, Nov 21, 2022
  6. Jeff KingNov 21, 2022
  7. Đoàn Trần Công DanhNov 23, 2022
  8. Jeff KingNov 24, 2022
  9. Ævar Arnfjörð BjarmasonNov 22, 2022
  10. Phillip WoodNov 22, 2022
  11. Junio C HamanoNov 23, 2022
  12. Phillip WoodNov 23, 2022
  13. Junio C HamanoNov 23, 2022
  14. Philippe BlainNov 22, 2022
  15. Philip OakleyNov 23, 2022
  16. Junio C HamanoNov 25, 2022
  17. Samuel FerencikApr 17, 2023
  18. Junio C HamanoApr 17, 2023
  19. Felipe ContrerasApr 18, 2023
  20. Johannes SchindelinApr 19, 2023
  21. Chris TorekApr 19, 2023
  22. Samuel FerencikApr 19, 2023
  23. rsbecker@nexbridge.comApr 19, 2023
  24. Junio C HamanoApr 19, 2023
  25. Junio C HamanoApr 19, 2023
  26. Junio C HamanoNov 22, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.