Rebase shears/next: 1 conflict(s) (0 skipped, 1 resolved) (#26503349023)#206
Open
gitforwindowshelper[bot] wants to merge 311 commits into
Open
Rebase shears/next: 1 conflict(s) (0 skipped, 1 resolved) (#26503349023)#206gitforwindowshelper[bot] wants to merge 311 commits into
gitforwindowshelper[bot] wants to merge 311 commits into
Conversation
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>
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>
The CMakeSettings.json file is tool generated. Developers may track it should they provide additional settings. Signed-off-by: Philip Oakley <philipoakley@iee.email>
Just like the `hash-object --literally` code path, the `--stdin` code path also needs to use `size_t` instead of `unsigned long` to represent memory sizes, otherwise it would cause problems on platforms using the LLP64 data model (such as Windows). To limit the scope of the test case, the object is explicitly not written to the object store, nor are any filters applied. The `big` file from the previous test case is reused to save setup time; To avoid relying on that side effect, it is generated if it does not exist (e.g. when running via `sh t1007-*.sh --long --run=1,41`). Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
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>
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>
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>
In Git-for-Windows, work on using ARM64 has progressed. The commit 2d94b77 (cmake: allow building for Windows/ARM64, 2020-12-04) failed to notice that /compat/vcbuild/vcpkg_install.bat will default to using the "x64-windows" architecture for the vcpkg installation if not set, but CMake is not told of this default. Commit 635b6d9 (vcbuild: install ARM64 dependencies when building ARM64 binaries, 2020-01-31) later updated vcpkg_install.bat to accept an arch (%1) parameter, but retained the default. This default is neccessary for the use case where the project directory is opened directly in Visual Studio, which will find and build a CMakeLists.txt file without any parameters, thus expecting use of the default setting. Also Visual studio will generate internal .sln solution and .vcxproj project files needed for some extension tools. Inform users of the additional .sln/.vcxproj generation. ** How to test: rm -rf '.vs' # remove old visual studio settings rm -rf 'compat/vcbuild/vcpkg' # remove any vcpkg downloads rm -rf 'contrib/buildsystems/out' # remove builds & CMake artifacts with a fresh Visual Studio Community Edition, File>>Open>>(git *folder*) to load the project (which will take some time!). check for successful compilation. The implicit .sln (etc.) are in the hidden .vs directory created by Visual Studio. Signed-off-by: Philip Oakley <philipoakley@iee.email>
To complement the `--stdin` and `--literally` test cases that verify that we can hash files larger than 4GB on 64-bit platforms using the LLP64 data model, here is a test case that exercises `hash-object` _without_ any options. Just as before, we use the `big` file from the previous test case if it exists to save on setup time, otherwise generate it. Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Special-casing even more configurations simply does not make sense. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows wants to add `git.exe` to the users' `PATH`, without cluttering the latter with unnecessary executables such as `wish.exe`. To that end, it invented the concept of its "Git wrapper", i.e. a tiny executable located in `C:\Program Files\Git\cmd\git.exe` (originally a CMD script) whose sole purpose is to set up a couple of environment variables and then spawn the _actual_ `git.exe` (which nowadays lives in `C:\Program Files\Git\mingw64\bin\git.exe` for 64-bit, and the obvious equivalent for 32-bit installations). Currently, the following environment variables are set unless already initialized: - `MSYSTEM`, to make sure that the MSYS2 Bash and the MSYS2 Perl interpreter behave as expected, and - `PLINK_PROTOCOL`, to force PuTTY's `plink.exe` to use the SSH protocol instead of Telnet, - `PATH`, to make sure that the `bin` folder in the user's home directory, as well as the `/mingw64/bin` and the `/usr/bin` directories are included. The trick here is that the `/mingw64/bin/` and `/usr/bin/` directories are relative to the top-level installation directory of Git for Windows (which the included Bash interprets as `/`, i.e. as the MSYS pseudo root directory). Using the absence of `MSYSTEM` as a tell-tale, we can detect in `git.exe` whether these environment variables have been initialized properly. Therefore we can call `C:\Program Files\Git\mingw64\bin\git` in-place after this change, without having to call Git through the Git wrapper. Obviously, above-mentioned directories must be _prepended_ to the `PATH` variable, otherwise we risk picking up executables from unrelated Git installations. We do that by constructing the new `PATH` value from scratch, appending `$HOME/bin` (if `HOME` is set), then the MSYS2 system directories, and then appending the original `PATH`. Side note: this modification of the `PATH` variable is independent of the modification necessary to reach the executables and scripts in `/mingw64/libexec/git-core/`, i.e. the `GIT_EXEC_PATH`. That modification is still performed by Git, elsewhere, long after making the changes described above. While we _still_ cannot simply hard-link `mingw64\bin\git.exe` to `cmd` (because the former depends on a couple of `.dll` files that are only in `mingw64\bin`, i.e. calling `...\cmd\git.exe` would fail to load due to missing dependencies), at least we can now avoid that extra process of running the Git wrapper (which then has to wait for the spawned `git.exe` to finish) by calling `...\mingw64\bin\git.exe` directly, via its absolute path. Testing this is in Git's test suite tricky: we set up a "new" MSYS pseudo-root and copy the `git.exe` file into the appropriate location, then verify that `MSYSTEM` is set properly, and also that the `PATH` is modified so that scripts can be found in `$HOME/bin`, `/mingw64/bin/` and `/usr/bin/`. This addresses git-for-windows#2283 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move the default `-ENTRY` and `-SUBSYSTEM` arguments for MSVC=1 builds from `config.mak.uname` into `clink.pl`. These args are constant for console-mode executables. Add support to `clink.pl` for generating a Win32 GUI application using the `-mwindows` argument (to match how GCC does it). This changes the `-ENTRY` and `-SUBSYSTEM` arguments accordingly. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
The previous commits introduced a compile-time option to load libcurl lazily, but it uses the hard-coded name "libcurl-4.dll" (or equivalent on platforms other than Windows). To allow for installing multiple libcurl flavors side by side, where each supports one specific SSL/TLS backend, let's first look whether `libcurl-<backend>-4.dll` exists, and only use `libcurl-4.dll` as a fall back. That will allow us to ship with a libcurl by default that only supports the Secure Channel backend for the `https://` protocol. This libcurl won't suffer from any dependency problem when upgrading OpenSSL to a new major version (which will change the DLL name, and hence break every program and library that depends on it). This is crucial because Git for Windows relies on libcurl to keep working when building and deploying a new OpenSSL package because that library is used by `git fetch` and `git clone`. Note that this feature is by no means specific to Windows. On Ubuntu, for example, a `git` built using `LAZY_LOAD_LIBCURL` will use `libcurl.so.4` for `http.sslbackend=openssl` and `libcurl-gnutls.so.4` for `http.sslbackend=gnutls`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
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>
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>
In the case of Git for Windows (say, in a Git Bash window) running in a Windows Subsystem for Linux (WSL) directory, the GetNamedSecurityInfoW() call in is_path_owned_By_current_side() returns an error code other than ERROR_SUCCESS. This is consistent behavior across this boundary. In these cases, the owner would always be different because the WSL owner is a different entity than the Windows user. The change here is to suppress the error message that looks like this: error: failed to get owner for '//wsl.localhost/...' (1) Before this change, this warning happens for every Git command, regardless of whether the directory is marked with safe.directory. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
For Windows builds >= 15063 set $env:TERM to "xterm-256color" instead of "cygwin" because they have a more capable console system that supports this. Also set $env:COLORTERM="truecolor" if unset. $env:TERM is initialized so that ANSI colors in color.c work, see 29a3963 (Win32: patch Windows environment on startup, 2012-01-15). See git-for-windows#3629 regarding problems caused by always setting $env:TERM="cygwin". This is the same heuristic used by the Cygwin runtime. Signed-off-by: Rafael Kitover <rkitover@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
NtQueryObject under Wine can return a success but fill out no name. In those situations, Wine will set Buffer to NULL, and set result to the sizeof(OBJECT_NAME_INFORMATION). Running a command such as echo "$(git.exe --version 2>/dev/null)" will crash due to a NULL pointer dereference when the code attempts to null terminate the buffer, although, weirdly, removing the subshell or redirecting stdout to a file will not trigger the crash. Code has been added to also check Buffer and Length to ensure the check is as robust as possible due to the current behavior being fragile at best, and could potentially change in the future This code is based on the behavior of NtQueryObject under wine and reactos. Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Atomic append on windows is only supported on local disk files, and it may cause errors in other situations, e.g. network file system. If that is the case, this config option should be used to turn atomic append off. Co-Authored-By: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: 孙卓识 <sunzhuoshi@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
From the documentation of said setting: This boolean will enable fsync() when writing object files. This is a total waste of time and effort on a filesystem that orders data writes properly, but can be useful for filesystems that do not use journalling (traditional UNIX filesystems) or that only journal metadata and not file contents (OS X’s HFS+, or Linux ext3 with "data=writeback"). The most common file system on Windows (NTFS) does not guarantee that order, therefore a sudden loss of power (or any other event causing an unclean shutdown) would cause corrupt files (i.e. files filled with NULs). Therefore we need to change the default. Note that the documentation makes it sound as if this causes really bad performance. In reality, writing loose objects is something that is done only rarely, and only a handful of files at a time. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Whith Windows 2000, Microsoft introduced a flag to the PE header to mark executables as "terminal server aware". Windows terminal servers provide a redirected Windows directory and redirected registry hives when launching legacy applications without this flag set. Since we do not use any INI files in the Windows directory and don't write to the registry, we don't need this additional preparation. Telling the OS that we don't need this should provide slightly improved startup times in terminal server environments. When building for supported Windows Versions with MSVC the /TSAWARE linker flag is automatically set, but MinGW requires us to set the --tsaware flag manually. This partially addresses git-for-windows#3935. Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Add FileVersion, which is a required field As not all required fields were present, none were being included Fixes git-for-windows#4090 Signed-off-by: Kiel Hurley <kielhurley@gmail.com>
In f9b7573 (repository: free fields before overwriting them, 2017-09-05), Git was taught to release memory before overwriting it, but 357a03e (repository.c: move env-related setup code back to environment.c, 2018-03-03) changed the code so that it would not _always_ be overwritten. As a consequence, the `commondir` attribute would point to already-free()d memory. This seems not to cause problems in core Git, but there are add-on patches in Git for Windows where the `commondir` attribute is subsequently used and causing invalid memory accesses e.g. in setups containing old-style submodules (i.e. the ones with a `.git` directory within theirs worktrees) that have `commondir` configured. This fixes git-for-windows#4083. Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is merely a historical wart that, say, `git-commit` exists in the `libexec/git-core/` directory, a tribute to the original idea to let Git be essentially a bunch of Unix shell scripts revolving around very few "plumbing" (AKA low-level) commands. Git has evolved a lot from there. These days, most of Git's functionality is contained within the `git` executable, in the form of "built-in" commands. To accommodate for scripts that use the "dashed" form of Git commands, even today, Git provides hard-links that make the `git` executable available as, say, `git-commit`, just in case that an old script has not been updated to invoke `git commit`. Those hard-links do not come cheap: they take about half a minute for every build of Git on Windows, they are mistaken for taking up huge amounts of space by some Windows Explorer versions that do not understand hard-links, and therefore many a "bug" report had to be addressed. The "dashed form" has been officially deprecated in Git version 1.5.4, which was released on February 2nd, 2008, i.e. a very long time ago. This deprecation was never finalized by skipping these hard-links, but we can start the process now, in Git for Windows. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 436a422 (max_tree_depth: lower it for clangarm64 on Windows, 2025-04-23), I provided a work-around for a nasty issue with clangarm builds, where the stack is exhausted before the maximal tree depth is reached, and the resulting error cannot easily be handled by Git (because it would require Windows-specific handling). Turns out that this is not at all limited to ARM64. In my tests with CLANG64 in MSYS2 on the GitHub Actions runners, the test t6700.4 failed in the exact same way. What's worse: The limit needs to be quite a bit lower for x86_64 than for aarch64. In aforementioned tests, the breaking point was 1232: With 1231 it still worked as expected, with 1232 it would fail with the `STATUS_STACK_OVERFLOW` incorrectly mapped to exit code 127. For comparison, in my tests on GitHub Actions' Windows/ARM64 runners, the breaking point was 1439 instead. Therefore the condition needs to be adapted once more, to accommodate (with some safety margin) both aarch64 and x86_64 in clang-based builds on Windows, to let that test pass. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…ctory Internally, Git expects the environment variable `HOME` to be set, and to point to the current user's home directory. This environment variable is not set by default on Windows, and therefore Git tries its best to construct one if it finds `HOME` unset. There are actually two different approaches Git tries: first, it looks at `HOMEDRIVE`/`HOMEPATH` because this is widely used in corporate environments with roaming profiles, and a user generally wants their global Git settings to be in a roaming profile. Only when `HOMEDRIVE`/`HOMEPATH` is either unset or does not point to a valid location, Git will fall back to using `USERPROFILE` instead. However, starting with Windows Vista, for secondary logons and services, the environment variables `HOMEDRIVE`/`HOMEPATH` point to Windows' system directory (usually `C:\Windows\system32`). That is undesirable, and that location is usually write-protected anyway. So let's verify that the `HOMEDRIVE`/`HOMEPATH` combo does not point to Windows' system directory before using it, falling back to `USERPROFILE` if it does. This fixes git-for-windows#2709 Initial-Path-by: Ivan Pozdeev <vano@mail.mipt.ru> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
headless-git is a git executable without opening a console window. It is useful when other GUI executables want to call git. We should install it together with git on Windows. Signed-off-by: Yuyi Wang <Strawberry_Str@hotmail.com>
This patch introduces support to set special NTFS attributes that are interpreted by the Windows Subsystem for Linux as file mode bits, UID and GID. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
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>
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>
…updates Start monitoring updates of Git for Windows' component in the open
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>
…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>
…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
…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
…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
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>
…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>
Add a README.md for GitHub goodness. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
…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).
This corresponds to gitgitgadget#2097.
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.
…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>
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>
…windows#6220) This includes gitgitgadget#2097 and a `fixup!` for a workflow that is not upstream (Nano Server).
…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.
…-for-windows#6232) This closes two gaps in the current `AGENTS.md` that came up while drafting git-for-windows#6231 and git-for-windows#2104: 1. The `Fixup Commits` section only covered `fixup!`. `amend!` has different semantics (replaces the target's commit message and combines diffs to produce any final state), and the "amend! whose body is the upstream commit and whose diff aligns the squashed result with that upstream commit" pattern is precisely how the first commit of git-for-windows#6231 anticipates the in-flight nedmalloc removal in `seen` as `e576abb9f8`. That pattern is undocumented today. 2. There is no top-level "Contributing to Git for Windows" section, only "Contributing to Upstream Git via GitGitGadget". The cross-fork `gh pr create` invocation, the conditions under which a PR is naturally a fixup/amend-only series against existing thicket commits, and the upstream-aligning `amend!` shape were all things I inferred from context rather than the guide. Add subsections that cover those gaps. Nothing in the existing text changes.
mingw: stop using nedmalloc The vendored nedmalloc allocator under compat/nedmalloc/ has been unmaintained upstream for a very long time: the original repository at https://github.com/ned14/nedmalloc received its last commit on July 5, 2014, and was archived (made read-only) by its owner on March 15, 2019. Our copy has been carried forward unchanged ever since. The Git for Windows commit that introduced mimalloc as a replacement on Windows ("mingw: use mimalloc", 2019-06-24, present in the Git for Windows branch thicket but not upstream) already observed at that time that nedmalloc had ceased to see any updates for several years. This came to a head when the Git for Windows SDK upgraded to GCC 16: the `add_segment()` function in `compat/nedmalloc/malloc.c.h` declares `int nfences = 0` and only references it inside an `assert()`, which GCC 16 now flags as `-Wunused-but-set-variable`. Combined with the `-Werror` enabled by `DEVELOPER=1`, this turns into a hard build failure: compat/nedmalloc/malloc.c.h: In function 'add_segment': compat/nedmalloc/malloc.c.h:3897:7: error: variable 'nfences' set but not used [-Werror=unused-but-set-variable=] 3897 | int nfences = 0; | ^~~~~~~ cc1.exe: all warnings being treated as errors The same source built without complaint under GCC 15.2.0; the regression was bisected to the SDK package update at git-for-windows/git-sdk-64@188d93dd455 (`mingw-w64-x86_64-gcc 15.2.0-14 -> 16.1.0-1`), with the failing CI run captured at https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074. Rather than patch the unmaintained vendored sources to silence the warning, stop opting into nedmalloc altogether on MINGW. The platform allocator is what every non-MINGW build already uses, and a fresh build of git.git's master against a minimal Git for Windows SDK upgraded to GCC 16, with `USE_NED_ALLOCATOR` removed from the MINGW section, completes successfully. The compat/nedmalloc/ subtree itself is left in place to keep this change minimal; nothing in the build links against it any longer, so it can be removed in a follow-up if desired. Assisted-by: Claude Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Re-running the `git repack -adfq` benchmark from 6a29c2d ("mingw: use mimalloc", 2019-06-24) against the platform's *current* default allocator (so without `nedmalloc` in the picture at all) shows mimalloc is no longer faster than the system allocator on any of Windows, macOS, or Linux, neither for the original ~30-second `linux v2.6.20` workload nor for a 4x larger `linux v3.0` workload where each individual run takes ~2 minutes (and the noise floor on Linux is below 0.3% of the mean, so even small differences would be visible if any existed). `mimalloc` was originally chosen over nedmalloc, not over the system allocator. Six years on, with nedmalloc now being dropped from the codebase entirely, the allocator that mimalloc has to beat is whatever the OS ships by default; modern Windows segment-heap, glibc malloc, and the macOS libsystem allocator have all closed the gap, and there is no longer a measurable benefit to keep maintaining a custom allocator. The actual benchmark methodology, the per-platform numbers, and links to the workflow runs that produced them are spelled out in the PR description rather than repeated across each fixup. The `fixup!` subject is so that the next rebase against an upstream Git that already lacks this commit will autosquash this revert into the original (which becomes empty and is dropped), leaving the tree free of `mimalloc`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork; the rationale (no measurable speedup over the platform allocator on any of Windows, macOS, or Linux) is in the second commit of the series and the PR description. The `fixup!` subject is so the next rebase against an upstream Git that already lacks the target commit autosquashes this revert into it, dropping the original cleanly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork; the rationale (no measurable speedup over the platform allocator on any of Windows, macOS, or Linux) is in the second commit of the series and the PR description. The `fixup!` subject is so the next rebase against an upstream Git that already lacks the target commit autosquashes this revert into it, dropping the original cleanly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork; the rationale (no measurable speedup over the platform allocator on any of Windows, macOS, or Linux) is in the second commit of the series and the PR description. The `fixup!` subject is so the next rebase against an upstream Git that already lacks the target commit autosquashes this revert into it, dropping the original cleanly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Part of the series that drops the vendored `mimalloc` from this fork; the rationale (no measurable speedup over the platform allocator on any of Windows, macOS, or Linux) is in the second commit of the series and the PR description. The original commit was a preparation step for vendoring `mimalloc` in (which forces C11 mode under mingw-w64 GCC and so implicitly links libwinpthread, clashing with Git's own emulation). With `mimalloc` gone the rename is no longer needed, so this revert restores the plain `pthread_create` / `pthread_self` names. The `fixup!` subject is so the next rebase against an upstream Git that already lacks the target commit autosquashes this revert into it, dropping the original cleanly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When 6a29c2d ("mingw: use mimalloc", 2019-06-24) introduced the vendored mimalloc, the comparison was against `nedmalloc` (which by then had not seen an upstream commit since 2014, and whose repository was archived in 2019). The two were essentially at parity in that benchmark; mimalloc was chosen because it was actively developed. I do not really recall whether the platform's *default* allocator was not part of the comparison; If it was, the performance was still worse than mimalloc, if it wasn't, I forgot to test ;-) Six years on, with `nedmalloc` safely on its way to being dropped from the upstream codebase entirely (gitgitgadget#2104, currently in `seen` as e576abb), the question is no longer "mimalloc vs nedmalloc" but "mimalloc vs the OS allocator". Re-running the same `git repack -adfq` benchmark against each platform's current default allocator finds no measurable speedup from mimalloc on any of Windows, macOS, or Linux. ## Methods I recapitulated the same benchmark as cited in 6a29c2d (the original comparison was nedmalloc vs mimalloc on `git repack -adfq` over a subset of `linux.git`), now extended to the three GitHub-hosted runners (`ubuntu-latest`, `macos-latest`, `windows-latest`). Each job built two `git` binaries from the same source tree, vanilla and `USE_MIMALLOC=YesPlease`, then prepared a fresh bare clone of `linux.git` to a fixed `SHA`, and ran the repacks with both built `git`s in randomized order for five iterations. Each iteration ran both binaries exactly once on a freshly `copytree`-ed copy of the immutable template repository; the order *within* an iteration was randomized so any per-iteration confounder (cache state, runner warm-up, neighbour-VM contention) would be shared symmetrically between variants. Timings excluded the `copytree`. The full driver is the Python script `ci/bench-mimalloc.py` on the [`mimalloc-benchmark` branch](https://github.com/dscho/git/tree/mimalloc-benchmark/ci). ## Results: original `linux v2.6.20`-era workload (49,917 commits, 431,605 objects, ~204 MB pack) | Platform | vanilla mean ± stdev | mimalloc mean ± stdev | Δ (mimalloc − vanilla) | |---|---|---|---| | `ubuntu-latest` | 27.089s ± 0.060s | 27.041s ± 0.065s | −0.048s (−0.18%) | | `macos-latest` | 23.259s ± 1.206s | 25.076s ± 2.279s | +1.817s (+7.8%) | | `windows-latest` | 29.828s ± 1.651s | 30.329s ± 2.428s | +0.501s (+1.7%) | Workflow run: https://github.com/dscho/git/actions/runs/25374127848 ## Results: 4x larger `linux v3.0` workload (255,039 commits, 2,059,429 objects, ~788 MB pack) | Platform | vanilla mean ± stdev | mimalloc mean ± stdev | Δ (mimalloc − vanilla) | |---|---|---|---| | `ubuntu-latest` | 134.723s ± **0.329s** | 134.801s ± **0.191s** | +0.078s (+0.06%) | | `macos-latest` | 130.183s ± 19.098s | 133.292s ± 18.991s | +3.109s (+2.4%) | | `windows-latest` | 145.183s ± 1.272s | 146.271s ± 4.161s | +1.088s (+0.75%) | Workflow run: https://github.com/dscho/git/actions/runs/25376885309 ## Discussion The Linux numbers on the larger workload are particularly clear: stdev is below 0.3% of the mean for both variants, and the difference is well inside that floor. Glibc's allocator and the vendored mimalloc are statistically indistinguishable for `git repack -adfq` here. `windows-latest` runners are noisier (per-run variance ~1-4%, mostly neighbour-VM scheduling), but mimalloc never beats vanilla in either workload. With the original justification for keeping a custom allocator gone (the modern Windows segment-heap is no longer the slow Windows-XP-era `HeapAlloc` that drove the original 2009 nedmalloc adoption), there is nothing left to motivate the maintenance cost of a vendored allocator. `macos-latest` is too noisy at n=5 (stdev 14% of the mean) to draw a firm conclusion, but the visible point-estimate goes the wrong way and there is no plausible mechanism by which Apple's `libsystem_malloc` would be slower than mimalloc. ## What this PR does *not* do It does not by itself remove `nedmalloc` from the tree; that is still promised as a follow-up of the in-flight upstream patch gitgitgadget#2104, presently in `seen` as e576abb. The first commit here is an `amend!` whose autosquashed result is byte-identical to that upstream commit, so once the next merging-rebase picks up the upstream patch the two will collapse cleanly. The five remaining `fixup!` reverts target each of the original mimalloc-vendoring commits in reverse chronological order; once autosquashed, the pairs cancel out to empty commits which the rebase will drop, leaving the tree free of `compat/mimalloc/`, the `USE_MIMALLOC` build infrastructure, and the supporting changes (`compat/posix.h` `_DEFAULT_SOURCE` guard, `win32_pthread_*` renames) that only existed to support the vendored allocator.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Workflow run
Rebase Summary: next
From: 9bf27a746a (Drop mimalloc (git-for-windows#6231), 2026-05-26) (9aa43b1219..9bf27a746a)
Resolved: 36f3132f55 (AGENTS.md: document
amend!, fixup-only PRs, and direct GfW PRs (git-for-windows#6232), 2026-05-26)Took HEAD version for files not touched by the merged branch (Makefile, compat/mingw.c, sideband.c, etc.); resolved AGENTS.md by keeping the new sections added by the merged branch (amend! commits docs, Contributing to Git for Windows section).
Range-diff
1: 36f3132f55 ! 1: 425804f AGENTS.md: document
amend!, fixup-only PRs, and direct GfW PRs (AGENTS.md: documentamend!, fixup-only PRs, and direct GfW PRs git#6232)@@ Commit message Add subsections that cover those gaps. Nothing in the existing text changes. + + ## AGENTS.md ## + remerge CONFLICT (add/add): Merge conflict in AGENTS.md + index d43956248c..377e9e9372 100644 + --- AGENTS.md + +++ AGENTS.md +@@ AGENTS.md: gets squashed into. + + Run affected tests before finalizing. + +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) +-================================ + ### `amend!` Commits + + A `fixup!` commit keeps the target's commit message and merely combines +@@ AGENTS.md: patches in the PR. + This is the preferred pattern for reverting a multi-commit downstream + feature. Order the fixups in **reverse** of the originals so each + revert applies cleanly to the worktree as you build the series. +- +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + ### Common Adaptation Patterns + + **Struct field moves**: When upstream moves fields between structs, update +@@ AGENTS.md: On Windows, `unsigned long` is 32 bits even on 64-bit systems. Use `size_t` + for sizes that may exceed 4GB. Be careful with format strings: use `PRIuMAX` + with a cast for `size_t` values. + +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) +-================================ + ## Contributing to Git for Windows + + The primary contribution path for this fork is a PR against +@@ AGENTS.md: message and whose diff aligns the autosquashed target with the + upstream commit's diff is the canonical pattern. The next + merging-rebase that picks up the upstream commit will recognize the + two as byte-identical and collapse them. +- +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + ## Contributing to Upstream Git via GitGitGadget + + ### Overview + + ## Documentation/config/sideband.adoc ## + remerge CONFLICT (add/add): Merge conflict in Documentation/config/sideband.adoc + index 074bd58d2a..96fade7f5f 100644 + --- Documentation/config/sideband.adoc + +++ Documentation/config/sideband.adoc +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters:: + By default, control characters that are delivered via the sideband + are masked, except ANSI color sequences. This prevents potentially + unwanted ANSI escape sequences from being sent to the terminal. Use +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + this config setting to override this behavior (the value can be + a comma-separated list of the following keywords): + + +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters:: + sideband.<url>.*:: + Apply the `sideband.*` option selectively to specific URLs. The + same URL matching logic applies as for `http.<url>.*` settings. +-======= +- this config setting to override this behavior: +-+ +--- +- color:: +- Allow ANSI color sequences, line feeds and horizontal tabs, +- but mask all other control characters. This is the default. +- false:: +- Mask all control characters other than line feeds and +- horizontal tabs. +- true:: +- Allow all control characters to be sent to the terminal. +--- +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + + ## Makefile ## + remerge CONFLICT (content): Merge conflict in Makefile + index 9c597e8b4e..b305c85f44 100644 + --- Makefile + +++ Makefile +@@ Makefile: BUILTIN_OBJS += builtin/write-tree.o + THIRD_PARTY_SOURCES += compat/inet_ntop.c + THIRD_PARTY_SOURCES += compat/inet_pton.c + THIRD_PARTY_SOURCES += compat/mimalloc/% +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) +-======= +-THIRD_PARTY_SOURCES += compat/nedmalloc/% +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + THIRD_PARTY_SOURCES += compat/obstack.% + THIRD_PARTY_SOURCES += compat/poll/% + THIRD_PARTY_SOURCES += compat/regex/% +@@ Makefile: CLAR_TEST_SUITES += u-hashmap + CLAR_TEST_SUITES += u-list-objects-filter-options + CLAR_TEST_SUITES += u-mem-pool + CLAR_TEST_SUITES += u-mingw +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + CLAR_TEST_SUITES += u-odb-inmemory +-======= +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + CLAR_TEST_SUITES += u-oid-array + CLAR_TEST_SUITES += u-oidmap + CLAR_TEST_SUITES += u-oidtree +@@ Makefile: endif + endif + + +-ifdef USE_MIMALLOC +- MIMALLOC_OBJS = \ +- compat/mimalloc/alloc-aligned.o \ +- compat/mimalloc/alloc.o \ +- compat/mimalloc/arena.o \ +- compat/mimalloc/bitmap.o \ +- compat/mimalloc/heap.o \ +- compat/mimalloc/init.o \ +- compat/mimalloc/libc.o \ +- compat/mimalloc/options.o \ +- compat/mimalloc/os.o \ +- compat/mimalloc/page.o \ +- compat/mimalloc/random.o \ +- compat/mimalloc/prim/prim.o \ +- compat/mimalloc/segment.o \ +- compat/mimalloc/segment-map.o \ +- compat/mimalloc/stats.o +- +- COMPAT_CFLAGS += -Icompat/mimalloc -DMI_DEBUG=0 -DUSE_MIMALLOC --std=gnu11 +- COMPAT_OBJS += $(MIMALLOC_OBJS) +- +-$(MIMALLOC_OBJS): COMPAT_CFLAGS += -DBANNED_H +- +-$(MIMALLOC_OBJS): COMPAT_CFLAGS += \ +- -DMI_WIN_USE_FLS \ +- -Wno-attributes \ +- -Wno-unknown-pragmas \ +- -Wno-unused-function \ +- -Wno-array-bounds +- +-ifdef DEVELOPER +-$(MIMALLOC_OBJS): COMPAT_CFLAGS += \ +- -Wno-pedantic \ +- -Wno-declaration-after-statement \ +- -Wno-old-style-definition \ +- -Wno-missing-prototypes \ +- -Wno-implicit-function-declaration +-endif +-endif +- + ifdef OVERRIDE_STRDUP + COMPAT_CFLAGS += -DOVERRIDE_STRDUP + COMPAT_OBJS += compat/strdup.o + + ## compat/mingw.c ## + remerge CONFLICT (content): Merge conflict in compat/mingw.c + index cebec2af0f..940243e0a3 100644 + --- compat/mingw.c + +++ compat/mingw.c +@@ compat/mingw.c: int mingw_unlink(const char *pathname, int handle_in_use_error) + return -1; + + if (use_legacy_delete < 0) +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + use_legacy_delete = git_env_bool("GIT_TEST_LEGACY_DELETE", 0); +-======= +- use_legacy_delete = !!getenv("GIT_TEST_LEGACY_DELETE"); +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + + if (try_delete_file(wpathname, use_legacy_delete)) + return 0; + + ## config.mak.dev ## + remerge CONFLICT (content): Merge conflict in config.mak.dev + index 7c09ebbae7..9906065b15 100644 + --- config.mak.dev + +++ config.mak.dev +@@ config.mak.dev: endif + endif + + ifneq ($(uname_S),FreeBSD) +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + ifneq ($(filter gcc6,$(COMPILER_FEATURES)),) +-======= +-ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter clang7,$(COMPILER_FEATURES))),) +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + ifndef USE_MIMALLOC + DEVELOPER_CFLAGS += -std=gnu99 + endif + + ## contrib/buildsystems/CMakeLists.txt ## + remerge CONFLICT (content): Merge conflict in contrib/buildsystems/CMakeLists.txt + index 79c560875c..9077b187e5 100644 + --- contrib/buildsystems/CMakeLists.txt + +++ contrib/buildsystems/CMakeLists.txt +@@ contrib/buildsystems/CMakeLists.txt: if(CMAKE_SYSTEM_NAME STREQUAL "Windows") + add_compile_definitions(HAVE_ALLOCA_H NO_POSIX_GOODIES NATIVE_CRLF NO_UNIX_SOCKETS WIN32 + _CONSOLE DETECT_MSYS_TTY STRIP_EXTENSION=".exe" NO_SYMLINK_HEAD UNRELIABLE_FSTAT + NOGDI OBJECT_CREATION_MODE=1 __USE_MINGW_ANSI_STDIO=0 +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP +-======= +- USE_NED_ALLOCATOR OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + HAVE_WPGMPTR HAVE_RTLGENRANDOM) + if(CMAKE_GENERATOR_PLATFORM STREQUAL "x64") + add_compile_definitions(ENSURE_MSYSTEM_IS_SET="MINGW64" MINGW_PREFIX="mingw64") +@@ contrib/buildsystems/CMakeLists.txt: if(CMAKE_SYSTEM_NAME STREQUAL "Windows") + compat/win32/trace2_win32_process_info.c + compat/win32/dirent.c + compat/win32/wsl.c +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) +-======= +- compat/nedmalloc/nedmalloc.c +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + compat/strdup.c + compat/win32/fscache.c) + set(NO_UNIX_SOCKETS 1) + + ## sideband.c ## + remerge CONFLICT (content): Merge conflict in sideband.c + index f98037f7c3..1523a53e1d 100644 + --- sideband.c + +++ sideband.c +@@ sideband.c: static struct keyword_entry keywords[] = { + }; + + static enum { +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + ALLOW_CONTROL_SEQUENCES_UNSET = -1, + ALLOW_NO_CONTROL_CHARACTERS = 0, + ALLOW_ANSI_COLOR_SEQUENCES = 1<<0, +@@ sideband.c: void sideband_apply_url_config(const char *url) + string_list_clear(&config.vars, 1); + urlmatch_config_release(&config); + } +-======= +- ALLOW_NO_CONTROL_CHARACTERS = 0, +- ALLOW_ALL_CONTROL_CHARACTERS = 1, +- ALLOW_ANSI_COLOR_SEQUENCES = 2 +-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES; +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + + /* Returns a color setting (GIT_COLOR_NEVER, etc). */ + static enum git_colorbool use_sideband_colors(void) +@@ sideband.c: static enum git_colorbool use_sideband_colors(void) + if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN) + return use_sideband_colors_cached; + +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) { + if (!repo_config_get_value(the_repository, "sideband.allowcontrolcharacters", &value)) + sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value); + + if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) + allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES; +-======= +- switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) { +- case 0: /* Boolean value */ +- allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS : +- ALLOW_NO_CONTROL_CHARACTERS; +- break; +- case -1: /* non-Boolean value */ +- if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters", +- &value)) +- ; /* huh? `get_maybe_bool()` returned -1 */ +- else if (!strcmp(value, "color")) +- allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES; +- else +- warning(_("unrecognized value for `sideband." +- "allowControlCharacters`: '%s'"), value); +- break; +- default: +- break; /* not configured */ +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + } + + if (!repo_config_get_string_tmp(the_repository, key, &value)) +@@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, const char *pref + list_config_item(list, prefix, keywords[i].keyword); + } + +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n) +-======= +-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n) +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + { + int i; + +@@ sideband.c: static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int + * Valid ANSI color sequences are of the form + * + * ESC [ [<n> [; <n>]*] m +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + * + * These are part of the Select Graphic Rendition sequences which + * contain more than just color sequences, for more details see +@@ sideband.c: static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int + strchr("ABCDEFGHf", src[i])) || + ((allow_control_characters & ALLOW_ANSI_ERASE) && + strchr("JKMPX", src[i]))) { +-======= +- */ +- +- if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES || +- n < 3 || src[0] != '\x1b' || src[1] != '[') +- return 0; +- +- for (i = 2; i < n; i++) { +- if (src[i] == 'm') { +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + strbuf_add(dest, src, i + 1); + return i; + } +@@ sideband.c: static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n) + { + int i; + +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) { +-======= +- if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) { +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + strbuf_add(dest, src, n); + return; + } + + strbuf_grow(dest, n); + for (; n && *src; src++, n--) { +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + if (!iscntrl(*src) || *src == '\t' || *src == '\n') { + strbuf_addch(dest, *src); + } else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS && + (i = handle_ansi_sequence(dest, src, n))) { +-======= +- if (!iscntrl(*src) || *src == '\t' || *src == '\n') +- strbuf_addch(dest, *src); +- else if ((i = handle_ansi_color_sequence(dest, src, n))) { +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + src += i; + n -= i; + } else { + strbuf_addch(dest, '^'); +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src); +-======= +- strbuf_addch(dest, 0x40 + *src); +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + } + } + } + + ## t/meson.build ## + remerge CONFLICT (content): Merge conflict in t/meson.build + index 8c834b039f..bd4b2e9c69 100644 + --- t/meson.build + +++ t/meson.build +@@ t/meson.build: clar_test_suites = [ + 'unit-tests/u-list-objects-filter-options.c', + 'unit-tests/u-mem-pool.c', + 'unit-tests/u-mingw.c', +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + 'unit-tests/u-odb-inmemory.c', +-======= +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + 'unit-tests/u-oid-array.c', + 'unit-tests/u-oidmap.c', + 'unit-tests/u-oidtree.c', + + ## t/t5409-colorize-remote-messages.sh ## + remerge CONFLICT (content): Merge conflict in t/t5409-colorize-remote-messages.sh + index d8f019c539..3010913bb1 100755 + --- t/t5409-colorize-remote-messages.sh + +++ t/t5409-colorize-remote-messages.sh +@@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' ' + printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2 + exec "$@" + EOF +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + test_config_global uploadPack.packObjectsHook ./color-me-surprised && +-================================ +- test_config_global uploadPack.packObjectshook ./color-me-surprised && +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + test_commit need-at-least-one-commit && + + git clone --no-local . throw-away 2>stderr && +@@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' ' + test_file_not_empty actual + ' + +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + test_decode_csi() { + awk '{ + while (match($0, /\033/) != 0) { +@@ t/t5409-colorize-remote-messages.sh: test_expect_success 'allow all control sequences for a specific URL' ' + test_grep ! "\\^\\[\\[K" decoded + ' + +-================================ +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + test_done + + ## t/t5563-simple-http-auth.sh ## + remerge CONFLICT (content): Merge conflict in t/t5563-simple-http-auth.sh + index e4fe33c258..aba09dccfe 100755 + --- t/t5563-simple-http-auth.sh + +++ t/t5563-simple-http-auth.sh +@@ t/t5563-simple-http-auth.sh: test_expect_success 'access using three-legged auth' ' + EOF + ' + +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + test_lazy_prereq SPNEGO 'curl --version | grep -qi "SPNEGO\|GSS-API\|Kerberos\|negotiate"' + + test_expect_success SPNEGO 'http.emptyAuth=auto attempts Negotiate before credential_fill' ' +@@ t/t5563-simple-http-auth.sh: test_expect_success SPNEGO 'http.emptyAuth=false skips Negotiate' ' + test_line_count = 1 actual_401s + ' + +-================================ +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + test_lazy_prereq NTLM 'curl --version | grep -q NTLM' + + test_expect_success NTLM 'access using NTLM auth' ' + + ## t/t9200-git-cvsexportcommit.sh ## + remerge CONFLICT (content): Merge conflict in t/t9200-git-cvsexportcommit.sh + index b0c68521d6..e2a86d7a90 100755 + --- t/t9200-git-cvsexportcommit.sh + +++ t/t9200-git-cvsexportcommit.sh +@@ t/t9200-git-cvsexportcommit.sh: case "$PWD" in + ;; + esac + +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + if ! cvs version >/dev/null 2>&1 +-================================ +-cvs >/dev/null 2>&1 +-if test $? -ne 1 +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + then + skip_all='skipping git cvsexportcommit tests, cvs not found' + test_done + + ## t/test-lib.sh ## + remerge CONFLICT (content): Merge conflict in t/test-lib.sh + index bc60ebcaae..30a1681884 100644 + --- t/test-lib.sh + +++ t/test-lib.sh +@@ + # You should have received a copy of the GNU General Public License + # along with this program. If not, see https://www.gnu.org/licenses/ . + +-<<<<<<< 9295ef82d5 (build: tolerate use of _Generic from glibc 2.43 with Clang (#6233)) + # Enable the use of errexit so that any unexpected failures will cause us to + # abort tests, even when outside of a specific test case. + # +@@ t/test-lib.sh: case "${GIT_TEST_USE_SET_E:-false}" in + ;; + esac + +-======= +->>>>>>> 35e8b3a205 (AGENTS.md: document `amend!`, fixup-only PRs, and direct GfW PRs) + # On Unix/Linux, the path separator is the colon, on other systems it + # may be different, though. On Windows, for example, it is a semicolon. + # If the PATH variable contains semicolons, it is pretty safe to assumeTo: 85b6edccc9 (Drop mimalloc (git-for-windows#6231), 2026-05-26) (4db57dc071..85b6edccc9)
Statistics
Range-diff (click to expand)
^$false match at end of filegit addissue with NTFS junctions.git/branches/in the templatescontrib/subtreetesttargetstrbuf_realpath()parse_interpreter()git-<command>for built-insCC = gcc--pic-executableETC_*for MSYS2 environmentsgit.exeto be used instead of the "Git wrapper"windows.appendAtomicallycontrib/subtreetests in CI buildswindows.appendAtomicallyin more caseslocaltime_r()is declared even in i686 buildsgit add <file>where <file> traverses an NTFS junction git#2504 from dscho/access-repo-via-junctionerrnois set correctly when socket operations failparse_interpreter()git#3165 from dscho/increase-allowed-length-of-interpreter-pathcontrib/subtreetest execution to CI builds git#3349 from vdye/feature/ci-subtree-testsunsigned long->size_tconversion to support large files on Windows git#3533 from PhilipOakley/hashliteral_tsafe.directorygit#3791: Various fixes aroundsafe.directorygit-<command>s for built-ins (Skip linking the "dashed"git-<command>s for built-ins git#4252)mingw-w64-git(i.e. regular MSYS2 ecosystem) support (Add fullmingw-w64-git(i.e. regular MSYS2 ecosystem) support git#5971)C:\Program Files\Git\mingw64\bin\git.exegit#2506 from dscho/issue-2283remove_dir_recurse()(Don't traverse mount points inremove_dir_recurse()git#6151)git p4testsgit p4tests (ci(macos): skip thegit p4tests git#5954)core.longPathsif paths are too long to removegit_terminal_promptwith more terminalssymlinkattributeiconviconvis unavailable, usetest-helper --iconvbuiltin pwd -Wwhen availableamend!, fixup-only PRs, and direct GfW PRs (AGENTS.md: documentamend!, fixup-only PRs, and direct GfW PRs git#6232)