Skip to content

Rebase shears/main (#25788127096)#162

Open
gitforwindowshelper[bot] wants to merge 305 commits into
base/shears/main-25788127096from
shears/main-25788127096
Open

Rebase shears/main (#25788127096)#162
gitforwindowshelper[bot] wants to merge 305 commits into
base/shears/main-25788127096from
shears/main-25788127096

Conversation

@gitforwindowshelper
Copy link
Copy Markdown

@gitforwindowshelper gitforwindowshelper Bot commented May 13, 2026

Workflow run

Rebase Summary: main

From: eaf875556a (build: tolerate use of _Generic from glibc 2.43 with Clang (git-for-windows#6233), 2026-05-08) (a547727dca..eaf875556a)
To: cb18d5e4db (build: tolerate use of _Generic from glibc 2.43 with Clang (git-for-windows#6233), 2026-05-08) (85f2d8d227..cb18d5e4db)

Statistics

Metric Count
Total conflicts 0
Skipped (upstreamed) 0
Resolved surgically 0
Range-diff (click to expand)

vdye and others added 30 commits May 13, 2026 08:44
@vdye
ci: run contrib/subtree tests in CI builds
5653e57 
Because `git subtree` (unlike most other `contrib` modules) is included as
part of the standard release of Git for Windows, its stability should be
verified as consistently as it is for the rest of git. By including the
`git subtree` tests in the CI workflow, these tests are as much of a gate to
merging and indicator of stability as the standard test suite.

Signed-off-by: Victoria Dye <vdye@github.com>
@PhilipOakley
CMake: show Win32 and Generator_platform build-option values
e93ede1 
Ensure key CMake option values are part of the CMake output to
facilitate user support when tool updates impact the wider CMake
actions, particularly ongoing 'improvements' in Visual Studio.

These CMake displays perform the same function as the build-options.txt
provided in the main Git for Windows. CMake is already chatty.
The setting of CMAKE_EXPORT_COMPILE_COMMANDS is also reported.

Include the environment's CMAKE_EXPORT_COMPILE_COMMANDS value which
may have been propogated to CMake's internal value.

Testing the CMAKE_EXPORT_COMPILE_COMMANDS processing can be difficult
in the Visual Studio environment, as it may be cached in many places.
The 'environment' may include the OS, the user shell, CMake's
own environment, along with the Visual Studio presets and caches.

See previous commit for arefacts that need removing for a clean test.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
@PhilipOakley
hash-object: add a >4GB/LLP64 test case using filtered input
195c4d3 
To verify that the `clean` side of the `clean`/`smudge` filter code is
correct with regards to LLP64 (read: to ensure that `size_t` is used
instead of `unsigned long`), here is a test case using a trivial filter,
specifically _not_ writing anything to the object store to limit the
scope of the test case.

As in previous commits, the `big` file from previous test cases is
reused if available, to save setup time, otherwise re-generated.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge branch 'fixes-from-the-git-mailing-list'
d27df31 
These fixes have been sent to the Git mailing list but have not been
picked up by the Git project yet.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@derrickstolee
survey: stub in new experimental 'git-survey' command
8802a78 
Start work on a new 'git survey' command to scan the repository
for monorepo performance and scaling problems.  The goal is to
measure the various known "dimensions of scale" and serve as a
foundation for adding additional measurements as we learn more
about Git monorepo scaling problems.

The initial goal is to complement the scanning and analysis performed
by the GO-based 'git-sizer' (https://github.com/github/git-sizer) tool.
It is hoped that by creating a builtin command, we may be able to take
advantage of internal Git data structures and code that is not
accessible from GO to gain further insight into potential scaling
problems.

Co-authored-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by: Derrick Stolee <stolee@gmail.com>
@dscho
mingw: stop hard-coding CC = gcc
e5cb16c 
This is no longer true in general, not with supporting Clang out of the
box.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
survey: add command line opts to select references
2ba289b 
By default we will scan all references in "refs/heads/", "refs/tags/"
and "refs/remotes/".

Add command line opts let the use ask for all refs or a subset of them
and to include a detached HEAD.

Signed-off-by: Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
@dscho
mingw: drop the -D_USE_32BIT_TIME_T option
21fd195 
This option was added in fa93bb2 (MinGW: Fix stat definitions to
work with MinGW runtime version 4.0, 2013-09-11), i.e. a _long_ time
ago. So long, in fact, that it still targeted MinGW. But we switched to
mingw-w64 in 2015, which seems not to share the problem, and therefore
does not require a fix.

Even worse: This flag is incompatible with UCRT64, which we are about to
support by way of upstreaming `mingw-w64-git` to the MSYS2 project, see
msys2/MINGW-packages#26470 for details.

So let's send that option into its well-deserved retirement.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge branch 'dscho-avoid-d-f-conflict-in-vs-master'
fb30db1 
Merge this early to resolve merge conflicts early.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@derrickstolee
survey: start pretty printing data in table form
f082e2d 
When 'git survey' provides information to the user, this will be presented
in one of two formats: plaintext and JSON. The JSON implementation will be
delayed until the functionality is complete for the plaintext format.

The most important parts of the plaintext format are headers specifying the
different sections of the report and tables providing concreted data.

Create a custom table data structure that allows specifying a list of
strings for the row values. When printing the table, check each column for
the maximum width so we can create a table of the correct size from the
start.

The table structure is designed to be flexible to the different kinds of
output that will be implemented in future changes.

Signed-off-by: Derrick Stolee <stolee@gmail.com>
@dscho
mingw: only use -Wl,--large-address-aware for 32-bit builds
dda24bb 
That option only matters there, and is in fact only really understood in
those builds; UCRT64 versions of GCC, for example, do not know what to
do with that option.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@jeffhostetler
clink.pl: fix libexpatd.lib link error when using MSVC
b8627b1 
When building with `make MSVC=1 DEBUG=1`, link to `libexpatd.lib`
rather than `libexpat.lib`.

It appears that the `vcpkg` package for "libexpat" has changed and now
creates `libexpatd.lib` for debug mode builds.  Previously, both debug
and release builds created a ".lib" with the same basename.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@derrickstolee
survey: add object count summary
00af883 
At the moment, nothing is obvious about the reason for the use of the
path-walk API, but this will become more prevelant in future iterations. For
now, use the path-walk API to sum up the counts of each kind of object.

For example, this is the reachable object summary output for my local repo:

REACHABLE OBJECT SUMMARY
========================
Object Type |  Count
------------+-------
       Tags |   1343
    Commits | 179344
      Trees | 314350
      Blobs | 184030

Signed-off-by: Derrick Stolee <stolee@gmail.com>
@dscho
mingw: avoid over-specifying --pic-executable
53080e1 
In bf2d5d8 (Don't let ld strip relocations, 2016-01-16) (picked from
git-for-windows@6a237925bf10),
Git for Windows introduced the `-Wl,-pic-executable` flag, specifying
the exact entry point via `-e`. This required discerning between i686
and x86_64 code because the former required the symbol to be prefixed
with an underscore, the latter did not.

As per https://sourceware.org/bugzilla/show_bug.cgi?id=10865, the
specified symbols are already the default, though.

So let's drop the overly-specific definition.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@jeffhostetler
Makefile: clean up .ilk files when MSVC=1
cbe1830 
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@derrickstolee
survey: summarize total sizes by object type
f3b297f 
Now that we have explored objects by count, we can expand that a bit more to
summarize the data for the on-disk and inflated size of those objects. This
information is helpful for diagnosing both why disk space (and perhaps
clone or fetch times) is growing but also why certain operations are slow
because the inflated size of the abstract objects that must be processed is
so large.

Note: zlib-ng is slightly more efficient even at those small sizes. Even
between zlib versions, there are slight differences in compression. To
accommodate for that in the tests, not the exact numbers but some rough
approximations are validated (the test should validate `git survey`,
after all, not zlib).

Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
mingw: set the prefix and HOST_CPU as per MSYS2's settings
bb7acce 
MSYS2 already defines a couple of helpful environment variables, and we
can use those to infer the installation location as well as the CPU. No
need for hard-coding ;-)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@jeffhostetler
vcbuild: add support for compiling Windows resource files
4b4c9d6 
Create a wrapper for the Windows Resource Compiler (RC.EXE)
for use by the MSVC=1 builds. This is similar to the CL.EXE
and LIB.EXE wrappers used for the MSVC=1 builds.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@derrickstolee
survey: show progress during object walk
e79dc79 
Signed-off-by: Derrick Stolee <stolee@gmail.com>
@dscho
mingw: make sure errno is set correctly when socket operations fail
c7a4367 
The winsock2 library provides functions that work on different data
types than file descriptors, therefore we wrap them.

But that is not the only difference: they also do not set `errno` but
expect the callers to enquire about errors via `WSAGetLastError()`.

Let's translate that into appropriate `errno` values whenever the socket
operations fail so that Git's code base does not have to change its
expectations.

This closes git-for-windows#2404

Helped-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
mingw: only enable the MSYS2-specific stuff when compiling in MSYS2
a6c3e8f 
The tell-tale is the presence of the `MSYSTEM` value while compiling, of
course. In that case, we want to ensure that `MSYSTEM` is set when
running `git.exe`, and also enable the magic MSYS2 tty detection.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@jeffhostetler
config.mak.uname: add git.rc to MSVC builds
b36c282 
Teach MSVC=1 builds to depend on the `git.rc` file so that
the resulting executables have Windows-style resources and
version number information within them.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@dscho
http: optionally load libcurl lazily
dbd3869 
This compile-time option allows to ask Git to load libcurl dynamically
at runtime.

Together with a follow-up patch that optionally overrides the file name
depending on the `http.sslBackend` setting, this kicks open the door for
installing multiple libcurl flavors side by side, and load the one
corresponding to the (runtime-)configured SSL/TLS backend.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@derrickstolee
survey: add ability to track prioritized lists
2956506 
In future changes, we will make use of these methods. The intention is to
keep track of the top contributors according to some metric. We don't want
to store all of the entries and do a sort at the end, so track a
constant-size table and remove rows that get pushed out depending on the
chosen sorting algorithm.

Co-authored-by: Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by; Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by: Derrick Stolee <stolee@gmail.com>
@rimrul
compat/mingw: handle WSA errors in strerror
4e25e27 
We map WSAGetLastError() errors to errno errors in winsock_error_to_errno(),
but the MSVC strerror() implementation only produces "Unknown error" for
most of them. Produce some more meaningful error messages in these
cases.

Our builds for ARM64 link against the newer UCRT strerror() that does know
these errors, so we won't change the strerror() used there.

The wording of the messages is copied from glibc strerror() messages.

Reported-by: M Hickford <mirth.hickford@gmail.com>
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
mingw: rely on MSYS2's metadata instead of hard-coding it
eaa6b1a 
MSYS2 defines some helpful environment variables, e.g. `MSYSTEM`. There
is code in Git for Windows to ensure that that `MSYSTEM` variable is
set, hard-coding a default.

However, the existing solution jumps through hoops to reconstruct the
proper default, and is even incomplete doing so, as we found out when we
extended it to support CLANGARM64.

This is absolutely unnecessary because there is already a perfectly
valid `MSYSTEM` value we can use at build time. This is even true when
building the MINGW32 variant on a MINGW64 system because `makepkg-mingw`
will override the `MSYSTEM` value as per the `MINGW_ARCH` array.

The same is equally true for the `/mingw64`, `/mingw32` and
`/clangarm64` prefix: those values are already available via the
`MINGW_PREFIX` environment variable, and we just need to pass that
setting through.

Only when `MINGW_PREFIX` is not set (as is the case in Git for Windows'
minimal SDK, where only `MSYSTEM` is guaranteed to be set correctly), we
use as fall-back the top-level directory whose name is the down-cased
value of the `MSYSTEM` variable.

Incidentally, this also broadens the support to all the configurations
supported by the MSYS2 project, i.e. clang64 & ucrt64, too.

Note: This keeps the same, hard-coded MSYSTEM platform support for CMake
as before, but drops it for Meson (because it is unclear how Meson could
do this in a more flexible manner).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
mingw: ensure valid CTYPE
b80a587 
A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified
how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime
derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls
for POSIX-1.2008, 2016-07-20).

An unintended side-effect is that "cold-calling" into the POSIX
emulation will start with a locale based on the current code page,
something that Git for Windows is very ill-prepared for, as it expects
to be able to pass a command-line containing non-ASCII characters to the
shell without having those characters munged.

One symptom of this behavior: when `git clone` or `git fetch` shell out
to call `git-upload-pack` with a path that contains non-ASCII
characters, the shell tried to interpret the entire command-line
(including command-line parameters) as executable path, which obviously
must fail.

This fixes git-for-windows#1036

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@jeffhostetler
clink.pl: ignore no-stack-protector arg on MSVC=1 builds
dc8f99b 
Ignore the `-fno-stack-protector` compiler argument when building
with MSVC.  This will be used in a later commit that needs to build
a Win32 GUI app.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@dscho
http: support lazy-loading libcurl also on Windows
24622f8 
This implements the Windows-specific support code, because everything is
slightly different on Windows, even loading shared libraries.

Note: I specifically do _not_ use the code from
`compat/win32/lazyload.h` here because that code is optimized for
loading individual functions from various system DLLs, while we
specifically want to load _many_ functions from _one_ DLL here, and
distinctly not a system DLL (we expect libcurl to be located outside
`C:\Windows\system32`, something `INIT_PROC_ADDR` refuses to work with).
Also, the `curl_easy_getinfo()`/`curl_easy_setopt()` functions are
declared as vararg functions, which `lazyload.h` cannot handle. Finally,
we are about to optionally override the exact file name that is to be
loaded, which is a goal contrary to `lazyload.h`'s design.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@derrickstolee
survey: add report of "largest" paths
43c1edd 
Since we are already walking our reachable objects using the path-walk API,
let's now collect lists of the paths that contribute most to different
metrics. Specifically, we care about

 * Number of versions.
 * Total size on disk.
 * Total inflated size (no delta or zlib compression).

This information can be critical to discovering which parts of the
repository are causing the most growth, especially on-disk size. Different
packing strategies might help compress data more efficiently, but the toal
inflated size is a representation of the raw size of all snapshots of those
paths. Even when stored efficiently on disk, that size represents how much
information must be processed to complete a command such as 'git blame'.

The exact disk size seems to be not quite robust enough for testing, as
could be seen by the `linux-musl-meson` job consistently failing, possibly
because of zlib-ng deflates differently: t8100.4(git survey
(default)) was failing with a symptom like this:

   TOTAL OBJECT SIZES BY TYPE
   ===============================================
   Object Type | Count | Disk Size | Inflated Size
   ------------+-------+-----------+--------------
  -    Commits |    10 |      1523 |          2153
  +    Commits |    10 |      1528 |          2153
         Trees |    10 |       495 |          1706
         Blobs |    10 |       191 |           101
  -       Tags |     4 |       510 |           528
  +       Tags |     4 |       547 |           528

This means: the disk size is unlikely something we can verify robustly.
Since zlib-ng seems to increase the disk size of the tags from 528 to
547, we cannot even assume that the disk size is always smaller than the
inflated size. We will most likely want to either skip verifying the
disk size altogether, or go for some kind of fuzzy matching, say, by
replacing `s/ 1[45][0-9][0-9] / ~1.5k /` and `s/ [45][0-9][0-9] / ~½k /`
or something like that.

Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho and others added 30 commits May 13, 2026 08:44
@dscho
Partially un-revert "editor: save and reset terminal after calling ED…
f309f8f 
…ITOR"

In e3f7e01 (Revert "editor: save and reset terminal after calling
EDITOR", 2021-11-22), we reverted the commit wholesale where the
terminal state would be saved and restored before/after calling an
editor.

The reverted commit was intended to fix a problem with Windows Terminal
where simply calling `vi` would cause problems afterwards.

To fix the problem addressed by the revert, but _still_ keep the problem
with Windows Terminal fixed, let's revert the revert, with a twist: we
restrict the save/restore _specifically_ to the case where `vi` (or
`vim`) is called, and do not do the same for any other editor.

This should still catch the majority of the cases, and will bridge the
time until the original patch is re-done in a way that addresses all
concerns.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge pull request git-for-windows#1170 from dscho/mingw-kill-process
bf29ffb 
Handle Ctrl+C in Git Bash nicely

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
README.md: Add a Windows-specific preamble
c82defd 
Includes touch-ups by 마누엘, Philip Oakley and 孙卓识.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
reset: reinstate support for the deprecated --stdin option
96784db 
The `--stdin` option was a well-established paradigm in other commands,
therefore we implemented it in `git reset` for use by Visual Studio.

Unfortunately, upstream Git decided that it is time to introduce
`--pathspec-from-file` instead.

To keep backwards-compatibility for some grace period, we therefore
reinstate the `--stdin` option on top of the `--pathspec-from-file`
option, but mark it firmly as deprecated.

Helped-by: Victoria Dye <vdye@github.com>
Helped-by: Matthew John Cheetham <mjcheetham@outlook.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge branch 'un-revert-editor-save-and-reset'
5a8a2fc 
A fix for calling `vim` in Windows Terminal caused a regression and was
reverted. We partially un-revert this, to get the fix again.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@shiftkey
Add an issue template
ce80efd 
With improvements by Clive Chan, Adric Norris, Ben Bodenmiller and
Philip Oakley.

Helped-by: Clive Chan <cc@clive.io>
Helped-by: Adric Norris <landstander668@gmail.com>
Helped-by: Ben Bodenmiller <bbodenmiller@hotmail.com>
Helped-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Brendan Forster <brendan@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho @rimrul
Add a GitHub workflow to monitor component updates
13d0d63 
Rather than using private IFTTT Applets that send mails to this
maintainer whenever a new version of a Git for Windows component was
released, let's use the power of GitHub workflows to make this process
publicly visible.

This workflow monitors the Atom/RSS feeds, and opens a ticket whenever a
new version was released.

Note: Bash sometimes releases multiple patched versions within a few
minutes of each other (i.e. 5.1p1 through 5.1p4, 5.0p15 and 5.0p16). The
MSYS2 runtime also has a similar system. We can address those patches as
a group, so we shouldn't get multiple issues about them.

Note further: We're not acting on newlib releases, OpenSSL alphas, Perl
release candidates or non-stable Perl releases. There's no need to open
issues about them.

Co-authored-by: Matthias Aßhauer <mha1993@live.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@vdye
fsmonitor: reintroduce core.useBuiltinFSMonitor
a54e953 
Reintroduce the 'core.useBuiltinFSMonitor' config setting (originally added
in 0a756b2 (fsmonitor: config settings are repository-specific,
2021-03-05)) after its removal from the upstream version of FSMonitor.

Upstream, the 'core.useBuiltinFSMonitor' setting was rendered obsolete by
"overloading" the 'core.fsmonitor' setting to take a boolean value. However,
several applications (e.g., 'scalar') utilize the original config setting,
so it should be preserved for a deprecation period before complete removal:

* if 'core.fsmonitor' is a boolean, the user is correctly using the new
  config syntax; do not use 'core.useBuiltinFSMonitor'.
* if 'core.fsmonitor' is unspecified, use 'core.useBuiltinFSMonitor'.
* if 'core.fsmonitor' is a path, override and use the builtin FSMonitor if
  'core.useBuiltinFSMonitor' is 'true'; otherwise, use the FSMonitor hook
  indicated by the path.

Additionally, for this deprecation period, advise users to switch to using
'core.fsmonitor' to specify their use of the builtin FSMonitor.

Signed-off-by: Victoria Dye <vdye@github.com>
@dscho
Merge branch 'phase-out-reset-stdin'
58d86b8 
This topic branch re-adds the deprecated --stdin/-z options to `git
reset`. Those patches were overridden by a different set of options in
the upstream Git project before we could propose `--stdin`.

We offered this in MinGit to applications that wanted a safer way to
pass lots of pathspecs to Git, and these applications will need to be
adjusted.

Instead of `--stdin`, `--pathspec-from-file=-` should be used, and
instead of `-z`, `--pathspec-file-nul`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Add an AGENTS.md file to help with AI-assisted debugging/development
d2c4c9a 
In this time and age, AI is everywhere. However, it's sometimes not very
easy to use. For green-field projects it works quite a bit better than
for existing legacy projects. And Git's source code is _quite_ as legacy
code as they come... 😁

Now, the only way how AI can be used efficiently with legacy code
is by providing enough information by way of prompt context for the
AI to have a chance to make any sense of the code. The structure and
the architecture is, after all, not designed for AI, but rather the
opposite: By virtue of having grown organically over two decades, there
is no design that AI coding models would readily grasp.

So here is a document that describes all kinds of aspects about this
project. The idea is to help AI by providing information that it does
not have ingrained in its weights. The idea is to provide information
that a human prompter might take for granted, but no coding model will
have been trained on specifically.

Assisted-by: Claude Opus 4.5
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Modify the GitHub Pull Request template (to reflect Git for Windows)
15b7ace 
Git for Windows accepts pull requests; Core Git does not. Therefore we
need to adjust the template (because it only matches core Git's
project management style, not ours).

Also: direct Git for Windows enhancements to their contributions page,
space out the text for easy reading, and clarify that the mailing list
is plain text, not HTML.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
dependabot: help keeping GitHub Actions versions up to date
0427e41 
See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot#enabling-dependabot-version-updates-for-actions for details.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge branch 'deprecate-core.useBuiltinFSMonitor'
1d13825 
Originally introduced as `core.useBuiltinFSMonitor` in Git for Windows
and developed, improved and stabilized there, the built-in FSMonitor
only made it into upstream Git (after unnecessarily long hemming and
hawing and throwing overly perfectionist style review sticks into the
spokes) as `core.fsmonitor = true`.

In Git for Windows, with this topic branch, we re-introduce the
now-obsolete config setting, with warnings suggesting to existing users
how to switch to the new config setting, with the intention to
ultimately drop the patch at some stage.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
fixup! Add an AGENTS.md file to help with AI-assisted debugging/devel…
1e7c9b8 
…opment

This adds an extensive section about resolving merge conflicts during
rebases, which happens quite often in Git for Windows' day-to-day.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
SECURITY.md: document Git for Windows' policies
59cb56a 
This is the recommended way on GitHub to describe policies revolving around
security issues and about supported versions.

Helped-by: Sven Strickroth <email@cs-ware.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge pull request git-for-windows#2837 from dscho/monitor-component-…
40480c7 
…updates

Start monitoring updates of Git for Windows' component in the open
@dscho
fixup! Add an AGENTS.md file to help with AI-assisted debugging/devel…
a1cc0ec 
…opment

AGENTS.md: add upstream contribution and worktree guidance

Add sections covering the GitGitGadget workflow for contributing to
upstream Git, commit message conventions specific to the upstream
project, how to manage patch series with dependencies (branch
thickets), effective worktree usage including --update-refs for
history rewrites, and techniques for analyzing merge-structured
topic branches with git replay.

These learnings come from a session contributing the
safe.bareRepository test preparation patches via GitGitGadget.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Claude Opus 4.6
@dscho
Merge 'readme' into HEAD
aabc573 
Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
fixup! Add an AGENTS.md file to help with AI-assisted debugging/devel…
b5de87b 
…opment

AGENTS.md: document rebase, staging, and log -L tricks for AI agents

Add practical recipes for three workflows that are particularly useful
when AI agents work with Git:

Non-interactive "interactive" rebases using `sed -i 1ib` as a sequence
editor to insert a `break` command, then editing the todo file directly
via the path from `git rev-parse --git-path rebase-merge/git-rebase-todo`.
This avoids the impossible task of driving an interactive editor from an
AI agent.

Scripted hunk staging via `printf '%s\n' s y q | git add -p`, which
feeds predictable keystrokes to the add-patch protocol to stage
individual hunks without human interaction.

The `git log -L <start>,+<count>:<file>` trick for finding which commit
last touched specific lines, enabling an `hg absorb`-like workflow where
the agent can identify the right fixup! target surgically rather than
grepping through full diffs.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Claude Opus 4.6
@dscho
fixup! Add an AGENTS.md file to help with AI-assisted debugging/devel…
c2465c4 
…opment

AGENTS.md: add pre-commit checklist for lint checks

Bundle the existing ASCII-only, 80-column, and whitespace validation
recipes into a "pre-commit checklist" block that agents should run
before every commit. The individual recipes already existed in the
Coding Conventions section but were presented as reference material
rather than as an actionable workflow step.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Claude Opus 4.6
@dscho
fixup! ci: work around a problem with HTTP/2 vs libcurl v8.10.0
94e41cd 
This was marked as a temporary work-around in 4538ee6 (ci: work
around a problem with HTTP/2 vs libcurl v8.10.0 (git-for-windows#5165), 2024-09-24), to
help CI builds pass even on macOS. The faulty libcurl version has hence
been replaced with plenty of fixed ones, therefore this work-around is
no longer necessary.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
fixup! Add an AGENTS.md file to help with AI-assisted debugging/devel…
db5fb05 
…opment

AGENTS: document learnings from split-index + fsmonitor investigation

While investigating a CI failure in the `linux-TEST-vars` job caused by
the interaction between the `pt/fsmonitor-linux` and
`hn/git-checkout-m-with-stash` topics in `seen`, several debugging
techniques proved essential and were not previously documented.

The investigation required bisecting the first-parent history of `seen`
while temporarily merging the fsmonitor topic at each step. This
revealed that `GIT_TEST_SPLIT_INDEX=yes` corrupts the bisect
machinery's own index operations unless it is unset before cleanup
checkouts. It also revealed that `fprintf(stderr, ...)` instrumentation
in Git's C code is swallowed by the test framework, making Trace2 the
correct instrumentation approach.

A key insight was that the bug appeared Linux-specific only because
`linux-TEST-vars` is the sole CI job setting `GIT_TEST_SPLIT_INDEX=yes`;
there is no macOS or Windows equivalent. The actual root cause (the
`index.skipHash=true` + split-index interaction producing a null
`base_oid` in the shared index) is platform-independent.

Add four documentation sections capturing these learnings: bisecting
`seen` interactions, reproducing with exact CI variables, verifying CI
platform coverage before concluding platform-specificity, and using
Trace2 for instrumentation inside the test framework.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Merge branch 'pr-2097'
a199309 
This corresponds to gitgitgadget#2097.
@dscho
fixup! revision: create mark_trees_uninteresting_dense()
077d01d 
This was a preparatory commit for the path-walk API, which has since
been upstreamed into v2.54.0. During the merging-rebase, the code
changes this commit introduced were already present in the new base,
leaving it empty. Drop it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Add an AGENTS.md file to help with AI-assisted debugging/development (g…
1728b71 
…it-for-windows#6198)

AI-assisted contributions are a reality of open source in 2025 and
beyond. Contributors will use AI tools, and that includes the
maintainers themselves. Over recent months, I have found AI increasingly
useful for the kind of menial, tedious work that does not require much
creativity but is highly boring when done by hand: resolving merge
conflicts during merging-rebases, chasing down CI failures across
platforms, adapting downstream patches to upstream API changes.

To that end, I would like to have an `AGENTS.md` file in the code base
that helps any LLM to understand the context of the project.

A secondary goal of this is to preemptively help outside contributors.
The risk is not AI usage per se, but low-quality AI slop: contributions
where the human hits "accept" without sufficient context being available
to the model (and without proper review by the human, we've all been
there), resulting in changes that miss conventions, break patterns, or
misunderstand the project's architecture. Git's source code is about as
legacy as they come, having grown organically over two decades with no
design that AI coding models would readily grasp from a narrow code
sample alone.

This `AGENTS.md` is designed to raise the floor on AI-assisted
contributions by providing enough context that even when a human
contributor fails to steer carefully, the model has the information it
needs to produce something reasonable. It documents the repository
structure, build process, test conventions, the object model and ODB
internals, debugging techniques (Trace2, instrumenting tests, bisecting
failures), the merging-rebase workflow, conflict resolution patterns,
coding conventions (ASCII only, 80 columns, tabs), commit message
expectations, and the GitGitGadget contribution workflow. This is
information that a human might take for granted, but no coding model
will have been trained on specifically.

Similar `AGENTS.md` files have recently been added to other repositories
in the Git for Windows project:
[MINGW-packages](git-for-windows/MINGW-packages#194),
[git-for-windows.github.io](git-for-windows/git-for-windows.github.io#88)
and
[msys2-runtime](git-for-windows/msys2-runtime@1e0ff37).
@dscho
fixup! Add a GitHub workflow to verify that Git/Scalar work in Nano S…
baf1b72 
…erver

Bump actions/checkout from v5 to v6 and
git-for-windows/setup-git-for-windows-sdk from v1 to v2.

Both bumps are Node.js 20 to Node.js 24 runtime migrations with
no functional changes to the actions themselves. checkout v6 moves
persisted credentials to `` instead of `.git/config`,
which does not affect this workflow since no subsequent steps rely
on the credential location. The setup-sdk v2 provisions the same
minimal SDK as v1.

Risk: very low. The only precondition is a recent Actions Runner,
which github.com-hosted runners already satisfy.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Drop obsolete downstream patches (git-for-windows#6208)
462d826 
Over time, as upstream Git absorbs fixes and features that originated in
or were carried by Git for Windows, downstream patches accumulate that
are no longer needed. The steady stream of merged PRs makes this
virtually inevitable. This PR collects fixup! commits to drop three such
patches during the next autosquash rebase.

The HTTP/2 workaround in `t5551` was a temporary fix for a libcurl
v8.10.0 regression on macOS CI runners. The faulty libcurl has long been
superseded by fixed versions, making it unnecessary.

The `unix-socket: avoid leak when initialization fails` patch changed
`return -1` to `goto fail` in `unix_stream_connect()` so cleanup would
run when `unix_sockaddr_init()` failed. Upstream fixed the same leak
more surgically in c5fe29f (unix-socket: fix memory leak when
chdir(3p) fails, 2025-01-30) by having `unix_sockaddr_init()` call
`FREE_AND_NULL(ctx->orig_dir)` before returning, making the downstream
caller-side fix redundant.

The `revision: create mark_trees_uninteresting_dense()` commit was a
preparatory patch for the path-walk API. That API has since been
upstreamed, and this commit became empty during the merging-rebase
because its changes were already in the new base.
@pks-t
build: tolerate use of _Generic from glibc 2.43 with Clang
54507fc 
When building with `make DEVELOPER=1` we explicitly pass "-std=gnu99" to
the compiler so that we don't start leaning on features exposed by more
recent versions of the C standard. Unfortunately though, glibc 2.43
started to use type-generic expressions. This works alright with GCC,
but when compiling with Clang this leads to errors:

  $ make DEVELOPER=1 CC=clang
  CC daemon.o
  In file included from daemon.c:3:
  ./git-compat-util.h:344:11: error: '_Generic' is a C11 extension [-Werror,-Wc11-extensions]
    344 |         return !!strchr(path, '/');
        |                  ^
  /usr/include/string.h:265:3: note: expanded from macro 'strchr'
    265 |   __glibc_const_generic (S, const char *, strchr (S, C))
        |   ^
  /usr/include/x86_64-linux-gnu/sys/cdefs.h:838:3: note: expanded from macro '__glibc_const_generic'
    838 |   _Generic (0 ? (PTR) : (void *) 1,                     \
        |   ^

In theory, the `__glibc_const_generic` macro does have feature gating:

  #if !defined __cplusplus \
      && (__GNUC_PREREQ (4, 9) \
          || __glibc_has_extension (c_generic_selections) \
          || (!defined __GNUC__ && defined __STDC_VERSION__ \
              && __STDC_VERSION__ >= 201112L))
  # define __HAVE_GENERIC_SELECTION 1
  #else
  # define __HAVE_GENERIC_SELECTION 0
  #endif

But this feature gating isn't effective because `_has_extension()` will
always evaluate to true as C generics _are_ available as a language
extension to GNU C99 when using Clang. This would have been different if
`_has_feature()` was used instead, in which case it would have properly
evaluated to `false`.

Unfortunately, there is no easy way for us to work around the warning.
We cannot define `__HAVE_GENERIC_SELECTION` ourselves as that would lead
to a redefinition, and given that the conditions are or'd together we
cannot disable any of those, either.

Instead, work around the issue by not using -std=gnu99 with Clang when
using the Makefile and by disabling warnings about C11 extensions when
using Meson. This isn't ideal, but we at least retain the ability to
detect the (mis-)use of features from newer standards with GCC.

An alternative to this might be to simply bump the required C standard
to C11, which is 15 years old by now and should have support on most
platforms out there. But some more esoteric platforms may not have it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Update GitHub Actions versions used in the GitHub workflows (git-for-…
850c503 
…windows#6220)

This includes gitgitgadget#2097 and a
`fixup!` for a workflow that is not upstream (Nano Server).
@dscho
build: tolerate use of _Generic from glibc 2.43 with Clang (git-for-w…
cb18d5e 
…indows#6233)

The `linux-{asan-ubsan,sha256,reftable}` jobs run inside
`ubuntu:rolling`, which now resolves to Ubuntu 26.04 with glibc 2.43;
that pulls `_Generic` into `<sys/cdefs.h>` and breaks our `-std=gnu99
-Werror` Clang builds. Concrete failure:
https://github.com/git-for-windows/git/actions/runs/25390480083/job/74463338845.

Picking up Patrick Steinhardt's fix from
https://lore.kernel.org/git/20260505-b4-pks-ci-tolerate-glibc-generic-v1-1-5786386fe512@pks.im/
ahead of its upstream merge so the GfW CI goes green again. The diff
conflicts with `fe5704a3695c "mimalloc: offer a build-time option to
enable it"`, which wraps the affected `config.mak.dev` block in `ifndef
USE_MIMALLOC`; the resolution preserves that wrap on the `gcc6`-only
branch surviving Patrick's patch. `meson.build` auto-merged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.