Hi Patrick, On Wed, 29 May 2024, Patrick Steinhardt wrote: > Now the question is why we use `SetEnvironmentVariableW()` over > `_putenv_s`, and whether changing it would be safe. The reason is that Git for Windows internally uses UTF-8 _always_. But `_putenv_s()` knows nothing of that choice, it uses the "active code page", which -- you guessed it -- is not at all controlled by `LC_CTYPE` but requires its own call to a Win32 Console API function. Now, there is theoretically that thing that you _could_ switch the active Win32 Console to CP_UTF8, i.e. the code page that corresponds to UTF-8. However, for that to work as well as Git for Windows' users deserve it, it would require a recent Windows 10 version, and Git for Windows still tries to support Windows 7 and Windows 8 [*1*]. For that reason, Git for Windows performs the conversion from UTF-8 to UTF-16 and then uses the `*W()` Win32 API function that accepts Unicode (no matter what the current code page is). With that in mind, I would love to find a solution that still uses that `*W()` Win32 API function. Ciao, Johannes Footnote *1*: That support was unfortunately already partially broken when Git LFS dropped support for Windows 7 and Windows 8, where it now fails with a segmentation fault (or "Access Violation" in Windows speak) and only prints a cryptic error message instead. For full details, see https://github.com/git-for-windows/git/issues/4996. You may note that this breakage was accepted and not reverted by the Git LFS team, citing security concerns ;-) So you could argue that Git for Windows is already somewhat broken for Windows versions prior to Windows 10, but that's not because of a carefully planned roadmap but instead due to forces that are outside my control.
