git/compat, branch v2.52.0

mingw: order `#include`s alphabetically

2025-10-09T20:21:28Z

It allows for more consistent patches that way. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: avoid relative `#include`s

2025-10-09T20:21:27Z

We want to make them relative to the top-level directory. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'js/mingw-fixes'

2025-08-04T15:10:34Z

Windows fixes. * js/mingw-fixes: mingw: support Windows Server 2016 again mingw_rename: support ReFS on Windows 2022 mingw: drop Windows 7-specific work-around mingw_open_existing: handle directories better

Merge branch 'ps/config-wo-the-repository'

2025-08-04T15:10:33Z

The config API had a set of convenience wrapper functions that implicitly use the_repository instance; they have been removed and inlined at the calling sites. * ps/config-wo-the-repository: (21 commits) config: fix sign comparison warnings config: move Git config parsing into "environment.c" config: remove unused `the_repository` wrappers config: drop `git_config_set_multivar()` wrapper config: drop `git_config_get_multivar_gently()` wrapper config: drop `git_config_set_multivar_in_file_gently()` wrapper config: drop `git_config_set_in_file_gently()` wrapper config: drop `git_config_set()` wrapper config: drop `git_config_set_gently()` wrapper config: drop `git_config_set_in_file()` wrapper config: drop `git_config_get_bool()` wrapper config: drop `git_config_get_ulong()` wrapper config: drop `git_config_get_int()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string_multi()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get()` wrapper config: drop `git_config_clear()` wrapper ...

mingw: support Windows Server 2016 again

2025-08-04T01:30:39Z

It was reported to the Git for Windows project that a simple `git init` fails on Windows Server 2016: D:\Dev\test> git init error: could not write config file D:/Dev/test/.git/config: Function not implemented fatal: could not set 'core.repositoryformatversion' to '0' According to https://endoflife.date/windows-server, Windows Server 2016 is officially supported for another one-and-a-half years as of time of writing, so this is not good. The culprit is the `mingw_rename()` changes that try to use POSIX semantics when available, but fail to fall back properly on Windows Server 2016. This fixes https://github.com/git-for-windows/git/issues/5695. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw_rename: support ReFS on Windows 2022

2025-08-04T01:30:39Z

ReFS is an alternative filesystem to NTFS. On Windows 2022, it seems not to support the rename operation using POSIX semantics that Git uses on Windows as of 391bceae4350 (compat/mingw: support POSIX semantics for atomic renames, 2024-10-27). However, Windows 2022 reports `ERROR_NOT_SUPPORTED` in this instance. This is in contrast to `ERROR_INVALID_PARAMETER` (as previous Windows versions would report that do not support POSIX semantics in renames at all). Let's handle both errors the same: by falling back to the best-effort option, namely to rename without POSIX semantics. This fixes https://github.com/git-for-windows/git/issues/5427 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: drop Windows 7-specific work-around

2025-08-04T01:30:38Z

In ac33519ddfa8 (mingw: restrict file handle inheritance only on Windows 7 and later, 2019-11-22), I introduced code to safe-guard the defense-in-depth handling that restricts handles' inheritance so that it would work with Windows 7, too. Let's revert this patch: Git for Windows dropped supporting Windows 7 (and Windows 8) directly after Git for Windows v2.46.2. For full details, see https://gitforwindows.org/requirements#windows-version. Actually, on second thought: revert only the part that makes this handle inheritance restriction logic optional and that suggests to open a bug report if it fails, but keep the fall-back to try again without said logic: There have been a few false positives over the past few years (where the warning was triggered e.g. because Defender was still accessing a file that Git wanted to overwrite), and the fall-back logic seems to have helped occasionally in such situations. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw_open_existing: handle directories better

2025-08-04T01:30:38Z

CreateFileW() requires FILE_FLAG_BACKUP_SEMANTICS to create a directory handle [1] and errors out with ERROR_ACCESS_DENIED without this flag. Fall back to accessing Directory handles this way. [1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#directories This fixes https://github.com/git-for-windows/git/issues/5068 Signed-off-by: Matthias Aßhauer Signed-off-by: Junio C Hamano

Merge branch 'ss/compat-bswap-revamp'

2025-07-24T23:03:56Z

Clean-up compat/bswap.h mess. * ss/compat-bswap-revamp: bswap.h: provide a built-in based version of bswap32/64 if possible bswap.h: remove optimized x86 version of bswap32/64 bswap.h: always overwrite ntohl/ ntohll macros bswap.h: define GIT_LITTLE_ENDIAN on msvc as little endian bswap.h: add support for __BYTE_ORDER__

config: drop `git_config_set()` wrapper

2025-07-23T15:15:21Z

In 036876a1067 (config: hide functions using `the_repository` by default, 2024-08-13) we have moved around a bunch of functions in the config subsystem that depend on `the_repository`. Those function have been converted into mere wrappers around their equivalent function that takes in a repository as parameter, and the intent was that we'll eventually remove those wrappers to make the dependency on the global repository variable explicit at the callsite. Follow through with that intent and remove `git_config_set()`. All callsites are adjusted so that they use `repo_config_set(the_repository, ...)` instead. While some callsites might already have a repository available, this mechanical conversion is the exact same as the current situation and thus cannot cause any regression. Those sites should eventually be cleaned up in a later patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano