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 <[email protected]>

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 <[email protected]>

Thu, Nov 6, 2025, 04:54:56 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <[email protected]>

Tue, Nov 4, 2025, 03:02:11 PM GMT

Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <[email protected]>

Tue, Nov 4, 2025, 12:20:57 PM GMT

git-svn: mark it as unsupported by the Git for Windows project (#5923)

There have been too many challenges supporting `git svn`, including lack
of participation in developing/maintaining the required stack.

See https://github.com/git-for-windows/git/issues/5405 for full details.

Mon, Oct 27, 2025, 08:11:19 PM GMT

diff: stop output garbled message in dry run mode

In dry run mode, diff_flush_patch() should not produce any output.
However, in commit b55e6d36eb (diff: ensure consistent diff behavior
with ignore options, 2025-08-08), only the output during the
comparison of two file contents was suppressed. For file deletions
or mode changes, diff_flush_patch() still produces output. In
run_extern_diff(), set quiet to true if in dry run mode. In
emit_diff_symbol_from_struct(), directly return if in dry run mode.

Signed-off-by: Lidong Yan <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

Fri, Oct 17, 2025, 12:11:27 PM GMT

diff: restore redirection to /dev/null for diff_from_contents

Note: This is _not_ strictly necessary, but adds a layer of protection
against bugs similar to the one that was reported very quickly after Git
v2.51.1 was released, one time via
https://lore.kernel.org/git/CACJRbWjwOQwJB13CwTfvhV3p+Hbn4KrNM9AtBanGtUS4V_1MbQ@mail.gmail.com/
and one time via
https://lore.kernel.org/git/[email protected]/.

In --quiet mode, since we produce only an exit code for "something was
changed" and no actual output, we can often get by with just a
tree-level diff. However, certain options require us to actually look at
the file contents (e.g., if we are ignoring whitespace changes). We have
a flag "diff_from_contents" for that, and if it is set we call
diff_flush() on each path.

To avoid producing any output (since we were asked to be --quiet), we
traditionally just redirected the output to /dev/null. That changed in
b55e6d36eb (diff: ensure consistent diff behavior with ignore options,
2025-08-08), which replaced that with a "dry_run" flag. In theory, with
dry_run set, we should produce no output. But it carries a risk of
regression: if we forget to respect dry_run in any of the output paths,
we'll accidentally produce output.

And indeed, there is at least one such regression in that commit, as it
covered only the case where we actually call into xdiff, and not
creation or deletion diffs, where we manually generate the headers. We
even test this case in t4035, but only with diff-tree, which does not
show the bug by default because it does not require diff_from_contents.
But git-diff does, because it allows external diff programs by default
(so we must dig into each diff filepair to decide if it requires running
an external diff that may declare two distinct blobs to actually be the
same).

We should fix all of those code paths to respect dry_run correctly, but
in the meantime we can protect ourselves more fully by restoring the
redirection to /dev/null. This gives us an extra layer of protection
against regressions dues to other code paths we've missed.

Though the original issue was reported with "git diff" (and due to its
default of --ext-diff), I've used "diff-tree -w" in the new test. It
triggers the same issue, but I think the fact that "-w" implies
diff_from_contents is a bit more obvious, and fits in with the rest of
t4035.

Reported-by: Jake Zimmerman <[email protected]>
Signed-off-by: Jeff King <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

Wed, Oct 8, 2025, 10:26:48 AM GMT

Fix `curl_easy_setopt()` parameter type problem, again (#5858)

As of three weeks ago, every CI build of Git for Windows' ARM64 flavor
of its SDK started failing (the first failed build is this
[here](https://github.com/git-for-windows/git-sdk-arm64/actions/runs/17633130672/job/50104373185)).

I had mistaken this for a problem with `git/git` and therefore tried to
fast-track (for some definition of "fast") the patch into `git/git`, but
I had forgotten that I changed `git-sdk-arm64`'s `ci-artifacts` workflow
[to build `git-for-windows/git`
instead](https://github.com/git-for-windows/git-sdk-arm64/commit/1b7ec02e29ae3638cf93b603ad2f9a2248b0e85e)
(because of the problems that needed to be fixed).

So let's integrate these patches into Git for Windows before they
trickle in via a new Git version (which is [currently scheduled for
November 17th, 2025](https://gh.io/gitCal)).

This is a companion of https://github.com/gitgitgadget/git/pull/1974.