Mon, Apr 6 2026 10:25:16 +0000

Detect number of cores better on multi-socket systems (#6108)

While the currently used way to detect the number of CPU cores ond
Windows is nice and straight-forward, GetSystemInfo() only [gives us
access to the number of processors within the current
group.](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members)

While that is usually fine for systems with a single physical CPU,
separate physical sockets are typically separate groups.

Switch to using GetLogicalProcessorInformationEx() to handle
multi-socket
systems better.

I've tested this on a physical single-socket x86-64 and a physical
dual-socket x86-64 system, and on a virtual single-socket ARM64 system.
Physical [multi-socket ARM64 systems seem to
exist](https://cloudbase.it/ampere-altra-industry-leading-arm64-server/),
but I don't have access to such hardware and the hypervisor I use
apparently can't emulate that either.

Mon, Apr 6 2026 07:16:14 +0000

Winansi: Drop pre-Vista workaround (#6109)

https://github.com/git-for-windows/git/commit/1edeb9abf5828e317999b4ebe8b7472c494341f2
(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.

This more or less fell out of #6108, but didn't quite fit into that PR.

There are also some other version specific hacks and workarounds I
considered dropping, but decided against:

*
https://github.com/git-for-windows/git/commit/492f70913e11de19bc4cb197b1fe195c645b89c9
* I'm unsure if this regression has ever been fixed or just become the
new normal.
* #5042
* So far this hasn't been an issue on Windows 8.1, but officially Go
1.21 and newer only support Windows 10 and newer. So this might become a
problem at any point.

Thu, Apr 2 2026 08:14:43 +0000

cmake: use writev(3p) wrapper as needed

This is a companion patch of 3b9b2c2a29a (compat/posix: introduce
writev(3p) wrapper, 2026-03-13) where support for using the `writev()`
wrapper was introduced in the `Makefile` and the Meson-based build, but
the CMake build still needs that treatment, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Tue, Mar 31 2026 11:20:45 +0000

Don't traverse mount points in `remove_dir_recurse()` (#6151)

`remove_dir_recurse()` in `dir.c` doesn't check for mount points, even
though this check was already added for `git clean` in #2268. So `git
worktree remove` (or anything else that calls it) will traverse NTFS
junctions and delete whatever is there. Similar to #607.

This extends the same check from #2268 but for anything that calls
`remove_dir_recurse()`.

Wed, Mar 25 2026 08:04:38 +0000

mingw: use strftime() directly in UCRT builds (#6130)

Currently, Git for Windows is built off of the MINGW64 tool chain. But
this will have to change because [the MSYS2 project deprecated this tool
chain in favor of
UCRT64](https://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environment).
Of course, that's only possible because they dropped support for Windows
8.1, which Git for Windows will probably have to do relatively soon. The
best time to do that is probably [the Git 3.0 inflection
point](https://github.com/git-for-windows/git/discussions/6018) when we
already promised to drop support for older Windows versions.

To prepare for such a huge change, I investigated what needs to be
changed in Git for Windows' source code. And the good news is there's
actually not very much. This here patch seems to be the only change
that's necessary, and not even _strictly_ necessary: the
`mingw_strftime()` wrapper would still do the right thing. It would just
uselessly load the same function that's already loaded, dynamically,
again.

- The `strerror()` override [is guarded by an `#ifndef
_UCRT`](https://github.com/git-for-windows/git/blob/v2.53.0.windows.2/compat/mingw-posix.h#L294-L296),
- `PRIuMAX` resolves to standard `"llu"` [via
`<inttypes.h>`](https://github.com/git-for-windows/git/blob/v2.53.0.windows.2/compat/mingw-posix.h#L449-L454)
(note that `__MINGW64_VERSION_MAJOR` is defined both in MINGW64 and
UCRT64, by virtue of using the `mingw-w64-headers`),
-
[`__USE_MINGW_ANSI_STDIO=0`](https://github.com/git-for-windows/git/blob/v2.53.0.windows.2/config.mak.uname#L751C19-L751C33)
is irrelevant because [`_UCRT` short-circuits
it](https://github.com/git-for-windows/git-sdk-64/blob/08933e673c79b5db48419917a2b02746b390afc4/mingw64/include/inttypes.h#L33),
and
- `SNPRINTF_RETURNS_BOGUS` hasn't been set for Git for Windows' builds
since ec47a33fd2c3b679c3d8cbd440752414adb56ce9, i.e. for a _really_ long
time.

Mon, Feb 2, 2026, 05:10:52 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Mon, Feb 2 2026 05:10:52 +0000

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Wed, Jan 28, 2026, 01:30:10 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Tue, Jan 27, 2026, 03:13:22 PM GMT

t/t5571-prep-push-hook.sh: Add test with writing to stderr (#6063)

Git v2.53.0-rc0 included f406b895529 (Merge branch
'ar/run-command-hook', 2026-01-06), which caused a regression on
Windows. While this merge was reverted for independent reasons in
a3d1f391d35 (Revert "Merge branch 'ar/run-command-hook'", 2026-01-15),
it seems worthwhile to ensure that writing to standard error from a
`pre-push` hook remains unbroken.

The symptom, when running this regression test case against
v2.53.0-rc0.windows.1 is that the `git push` fails, with this message
printed to standard error:

.git/hooks/pre-push: line 2: /dev/stderr: No such file or
direct[61/1940]
   error: failed to push some refs to 'repo1'

When that hook runs, `/dev/stderr` is a symlink to `/proc/self/fd/2`, as
always, but `ls -l /proc/self/fd/` shows this in the failing run

  total 0
  lrwxrwxrwx 1 me 4096 0 Jan 27 14:34 0 -> pipe:[0]
  lrwxrwxrwx 1 me 4096 0 Jan 27 14:34 1 -> pipe:[0]
  lrwxrwxrwx 1 me 4096 0 Jan 27 14:34 2 -> pipe:[0]

instead of the expected contents (which are shown when running this
against v2.53.0-rc1.windows.1):

  total 0
  lrwxrwxrwx 1 me 4096 0 Jan 27 14:53 0 -> 'pipe:[0]'
  lrwxrwxrwx 1 me 4096 0 Jan 27 14:53 1 -> /dev/cons1
lrwxrwxrwx 1 me 4096 0 Jan 27 14:53 2 -> '/path/to/git/t/trash
directory.t5571-pre-push-hook/actual'

This suggests that the underlying reason might be that `stdout` has an
exclusive handle to that pipe, and opening `stderr` (which points to the
same pipe) fails because of that exclusively-opened `stdout` handle.

This closes https://github.com/git-for-windows/git/issues/6053.

Thu, Jan 22, 2026, 05:00:57 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>