git/compat, branch next

Merge branch 'js/mingw-no-nedmalloc' into next

2026-05-13T03:21:27Z

Stop using unmaintained custom allocator in Windows build which was the last user of the code. * js/mingw-no-nedmalloc: mingw: remove the vendored compat/nedmalloc/ subtree mingw: drop the build-system plumbing for nedmalloc mingw: stop using nedmalloc

Merge branch 'js/objects-larger-than-4gb-on-windows' into next

2026-05-13T03:21:26Z

Update code paths that assumed "unsigned long" was long enough for "size_t". * js/objects-larger-than-4gb-on-windows: ci: run expensive tests on push builds to integration branches t5608: mark >4GB tests as EXPENSIVE test-tool synthesize: add precomputed SHA-256 pack for 4 GiB + 1 test-tool synthesize: precompute pack for 4 GiB + 1 test-tool synthesize: use the unsafe hash for speed t5608: add regression test for >4GB object clone test-tool: add a helper to synthesize large packfiles delta, packfile: use size_t for delta header sizes odb, packfile: use size_t for streaming object sizes git-zlib: handle data streams larger than 4GB index-pack, unpack-objects: use size_t for object size

test-tool: add a helper to synthesize large packfiles

2026-05-09T02:25:32Z

To test Git's behavior with very large pack files, we need a way to generate such files quickly. A naive approach using only readily-available Git commands would take over 10 hours for a 4GB pack file, which is prohibitive. Side-stepping Git's machinery and actual zlib compression by writing uncompressed content with the appropriate zlib header makes things much faster. The fastest method using this approach generates many small, unreachable blob objects and takes about 1.5 minutes for 4GB. However, this cannot be used because we need to test git clone, which requires a reachable commit history. Generating many reachable commits with small, uncompressed blobs takes about 4 minutes for 4GB. But this approach 1) does not reproduce the issues we want to fix (which require individual objects larger than 4GB) and 2) is comparatively slow because of the many SHA-1 calculations. The approach taken here generates a single large blob (filled with NUL bytes), along with the trees and commits needed to make it reachable. This takes about 2.5 minutes for 4.5GB, which is the fastest option that produces a valid, clonable repository with an object large enough to trigger the bugs we want to test. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: remove the vendored compat/nedmalloc/ subtree

2026-05-09T02:20:12Z

The previous two commits stopped opting into nedmalloc on Windows and stripped out the build-system plumbing that referenced it; the compat/nedmalloc/ subtree now has no callers and no consumers in the build, so retire it from the tree. Note that this patch is larger than can be sent via the mailing list, and was originally sent in three-pieces and merged back on the receiving end. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: optionally use legacy (non-POSIX) delete semantics

2026-05-08T00:53:12Z

At some point between Windows 10 Build 17134.1304 and Build 18363.657, the default behavior of `DeleteFileW()` was changed to use POSIX semantics (https://stackoverflow.com/a/60512798). Under those semantics, a file can be deleted even when another process holds an active `MapViewOfFile` view on it: the directory entry is removed immediately, but the underlying data persists until the last handle is closed. On older Windows versions (and Windows 10 builds before that change), `DeleteFileW()` uses legacy semantics where deletion fails outright if any process holds a file mapping. To allow testing code paths that depend on the legacy behavior, introduce a `GIT_TEST_LEGACY_DELETE` environment variable. When set, `mingw_unlink()` uses `SetFileInformationByHandle()` with `FileDispositionInfo` (the non-POSIX variant) instead of `DeleteFileW()`, forcing legacy delete semantics regardless of the Windows version. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Revert "compat/posix: introduce writev(3p) wrapper"

2026-04-09T21:48:24Z

This reverts commit 3b9b2c2a29a1d529ca9884fa0a6529f6e2496abe; let's not use writev() for now.

compat/winansi: drop pre-Vista workaround

2026-04-06T17:06:22Z

1edeb9a (Win32: warn if the console font doesn't support Unicode, 2014-06-10) introduced both code to detect the current console font on Windows Vista and newer and a fallback for older systems to detect the default console font and issue a warning if that font doesn't support unicode. Since we haven't supported any Windows older than Vista in almost a decade, we don't need to keep the workaround. Signed-off-by: Matthias Aßhauer Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

unify and bump _WIN32_WINNT definition to Windows 8.1

2026-04-06T17:06:20Z

Git for Windows doesn't support anything prior to Windows 8.1 since 2.47.0 and Git followed along with commits like ce6ccba (mingw: drop Windows 7-specific work-around, 2025-08-04). There is no need to pretend to the compiler that we still support Windows Vista, just to lock us out of easy access to newer APIs. There is also no need to have conflicting and unused definitions claiming we support some versions of Windows XP or even Windows NT 4.0. Bump all definitions of _WIN32_WINNT to a realistic value of Windows 8.1. This will also simplify code for a followup commit that will improve cpu core detection on multi-socket systems. Signed-off-by: Matthias Aßhauer Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: use strftime() directly in UCRT builds

2026-04-03T17:36:48Z

The `mingw_strftime()` wrapper exists to work around msvcrt.dll's incomplete `strftime()` implementation by dynamically loading the version from ucrtbase.dll at runtime via `LoadLibrary()` + `GetProcAddress()`. When the binary is already linked against UCRT (i.e. when building in the UCRT64 environment), the linked-in `strftime()` is the ucrtbase.dll version, making the dynamic loading needless churn: It's calling the very same code. Simply guard both the declaration and implementation so that the unnecessary work-around is skipped in UCRT builds. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

regexp: leave a pointer to resurrect workaround for Homebrew

2026-03-25T22:04:30Z

Recently some GitHub CI jobs were broken by update on the platform side, which was eventually resolved by image rollback, but in the meantime Dscho invented a workaround patch to sidestep the broken part of the platform. Their future image update may contain the same bug, in which case the workaround may again become needed. As we do not want to be building with workaround that avoids system regexp library altogether unless the system is known to be broken, so short of an automated "detect broken system and apply workaround" mechanism, let's use the folks who are compiling the code to detect breakage on their system and cope with the breakage ;-) Signed-off-by: Junio C Hamano