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>

Fri, Jan 16, 2026, 12:23:56 AM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

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

Thu, Jan 15, 2026, 11:14:01 PM GMT

Reword `mingw: support long paths` (#6013)

- see
https://github.com/git-for-windows/git/commit/8093ade2297d90401e89dc5123e03dfedf99422e#commitcomment-173292269,
https://github.com/git-for-windows/git/pull/5957#issuecomment-3691447245

For the commit message:
```diff
 This is to prevent end
-users to shoot themselves in the foot by checking out files that Windows
+users from shooting themselves in the foot by checking out files that Windows
 Explorer, cmd/bash or their favorite IDE cannot handle.
```

Thu, Jan 15, 2026, 09:39:29 AM GMT

Ugrade mimalloc to 2.2.6 (#6034)

This fixes #6029

Tue, Nov 25, 2025, 09:17:57 PM GMT

Add full `mingw-w64-git` (i.e. regular MSYS2 ecosystem) support (#5971)

Every once in a while, there are bug reports in Git for Windows' bug
tracker that describe an issue running [inside MSYS2
proper](https://gitforwindows.org/install-inside-msys2-proper), totally
ignoring the big, honking warning on top of [the
page](https://gitforwindows.org/install-inside-msys2-proper) that spells
out clearly that this is an unsupported use case.

At the same time, we cannot easily deflect and say "just use MSYS2
directly" (and leave the "and stop pestering us" out). We cannot do that
because there is only an _MSYS_ `git` package in MSYS2 (i.e. a Git that
uses the quite slow POSIX emulation layer provided by the MSYS2
runtime), but no `mingw-w64-git` package (which would be equivalent in
speed to Git for Windows).

In https://github.com/msys2/MINGW-packages/pull/26470, I am preparing to
change that. As part of that PR, I noticed and fixed a couple of issues
_in `git-for-windows/git` that prevented full support for
`mingw-w64-git` in MSYS2, such as problems with CLANG64 and UCRT64.

While at it, I simplified the entire setup to trust MSYS2's
`MINGW_PREFIX` & related environment variables instead of hard-coding
values like the installation prefix and what `MSYSTEM` to fall back on
if it is unset.

Mon, Nov 17, 2025, 05:01:44 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

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

Fri, Nov 14, 2025, 10:46:28 AM GMT

ci(macos): skip the `git p4` tests (#5954)

Historically, the macOS jobs have always been among the longest-running
ones, and recently the `git p4` tests became another liability: They
started to fail much more often (maybe as of the switch away from the
`macos-13` pool?), requiring re-runs of the jobs that already were
responsible for long CI build times.

Of the 35 test scripts that exercise `git p4`, 32 are actually run on
macOS (3 are skipped for reasons like case-sensitivee filesystem), and
they take an accumulated runtime of over half an hour.

Furthermore, the `git p4` command is not really affected by Git for
Windows' patches, at least not as far as macOS is concerned, therefore
it is not only causing developer friction to have these long-running,
frequently failing tests, it is also quite wasteful: There has not been
a single instance so far where any `git p4` test failure in Git for
Windows had demonstrated an actionable bug.

So let's just disable those tests in the CI runs, at least on macOS.

Wed, Nov 12, 2025, 06:18:21 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

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