-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Rebase to v2.40.0-rc0 #4316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebase to v2.40.0-rc0 #4316
Conversation
In this context, a "feature" is a dependency combined with its own dependencies. Signed-off-by: Ian Bearman <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Dennis Ameling <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
There are no Windows/ARM64 agents in GitHub Actions yet, therefore we just skip adjusting the `vs-test` job for now. Signed-off-by: Dennis Ameling <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
The vcpkg downloads may not succeed. Warn careful readers of the time out. A simple retry will usually resolve the issue. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Dennis Ameling <[email protected]>
Git's regular Makefile mentions that HOST_CPU should be defined when cross-compiling Git: https://github.com/git-for-windows/git/blob/37796bca76ef4180c39ee508ca3e42c0777ba444/Makefile#L438-L439 This is then used to set the GIT_HOST_CPU variable when compiling Git: https://github.com/git-for-windows/git/blob/37796bca76ef4180c39ee508ca3e42c0777ba444/Makefile#L1337-L1341 Then, when the user runs `git version --build-options`, it returns that value: https://github.com/git-for-windows/git/blob/37796bca76ef4180c39ee508ca3e42c0777ba444/help.c#L658 This commit adds the same functionality to the CMake configuration. Users can now set -DHOST_CPU= to set the target architecture. Signed-off-by: Dennis Ameling <[email protected]>
We now have a GitHub Action to download and cache Azure Pipelines artifacts (such as the `vcpkg` artifacts), hiding gnarly internals, and also providing some robustness against network glitches. Let's use it. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in newren/git-filter-repo#225, it looks like 99 bytes is not really sufficient to represent e.g. the full path to Python when installed via Windows Store (and this path is used in the hasb bang line when installing scripts via `pip`). Let's increase it to what is probably the maximum sensible path size: MAX_PATH. This makes `parse_interpreter()` in line with what `lookup_prog()` handles. Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Vilius Šumskas <[email protected]>
Correct some wording and inform users regarding the Visual Studio changes (from V16.6) to the default generator. Subsequent commits ensure that Git for Windows can be directly opened in modern Visual Studio without needing special configuration of the CMakeLists settings. It appeares that internally Visual Studio creates it's own version of the .sln file (etc.) for extension tools that expect them. The large number of references below document the shifting of Visual Studio default and CMake setting options. refs: https://docs.microsoft.com/en-us/search/?scope=C%2B%2B&view=msvc-150&terms=Ninja 1. https://docs.microsoft.com/en-us/cpp/linux/cmake-linux-configure?view=msvc-160 (note the linux bit) "In Visual Studio 2019 version 16.6 or later ***, Ninja is the default generator for configurations targeting a remote system or WSL. For more information, see this post on the C++ Team Blog [https://devblogs.microsoft.com/cppblog/linux-development-with-visual-studio-first-class-support-for-gdbserver-improved-build-times-with-ninja-and-updates-to-the-connection-manager/]. For more information about these settings, see CMakeSettings.json reference [https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-160]." 2. https://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160 "CMake supports two files that allow users to specify common configure, build, and test options and share them with others: CMakePresets.json and CMakeUserPresets.json." " Both files are supported in Visual Studio 2019 version 16.10 or later. ***" 3. https://devblogs.microsoft.com/cppblog/linux-development-with-visual-studio-first-class-support-for-gdbserver-improved-build-times-with-ninja-and-updates-to-the-connection-manager/ " Ninja has been the default generator (underlying build system) for CMake configurations targeting Windows for some time***, but in Visual Studio 2019 version 16.6 Preview 3*** we added support for Ninja on Linux." 4. https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-160 " `generator`: specifies CMake generator to use for this configuration. May be one of: Visual Studio 2019 only: Visual Studio 16 2019 Visual Studio 16 2019 Win64 Visual Studio 16 2019 ARM Visual Studio 2017 and later: Visual Studio 15 2017 Visual Studio 15 2017 Win64 Visual Studio 15 2017 ARM Visual Studio 14 2015 Visual Studio 14 2015 Win64 Visual Studio 14 2015 ARM Unix Makefiles Ninja Because Ninja is designed for fast build speeds instead of flexibility and function, it is set as the default. However, some CMake projects may be unable to correctly build using Ninja. If this occurs, you can instruct CMake to generate Visual Studio projects instead. To specify a Visual Studio generator in Visual Studio 2017, open the settings editor from the main menu by choosing CMake | Change CMake Settings. Delete "Ninja" and type "V". This activates IntelliSense, which enables you to choose the generator you want." "To specify a Visual Studio generator in Visual Studio 2019, right-click on the CMakeLists.txt file in Solution Explorer and choose CMake Settings for project > Show Advanced Settings > CMake Generator. When the active configuration specifies a Visual Studio generator, by default MSBuild.exe is invoked with` -m -v:minimal` arguments." 5. https://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160#enable-cmakepresetsjson-integration-in-visual-studio-2019 "Enable CMakePresets.json integration in Visual Studio 2019 CMakePresets.json integration isn't enabled by default in Visual Studio 2019. You can enable it for all CMake projects in Tools > Options > CMake > General: (tick a box)" ... see more. 6. https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-140 (whichever v140 is..) "CMake projects are supported in Visual Studio 2017 and later." 7. https://docs.microsoft.com/en-us/cpp/overview/what-s-new-for-cpp-2017?view=msvc-150 "Support added for the CMake Ninja generator." 8. https://docs.microsoft.com/en-us/cpp/overview/what-s-new-for-cpp-2017?view=msvc-150#cmake-support-via-open-folder "CMake support via Open Folder Visual Studio 2017 introduces support for using CMake projects without converting to MSBuild project files (.vcxproj). For more information, see CMake projects in Visual Studio[https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=msvc-150]. Opening CMake projects with Open Folder automatically configures the environment for C++ editing, building, and debugging." ... +more! 9. https://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160#supported-cmake-and-cmakepresetsjson-versions "Visual Studio reads and evaluates CMakePresets.json and CMakeUserPresets.json itself and doesn't invoke CMake directly with the --preset option. So, CMake version 3.20 or later isn't strictly required when you're building with CMakePresets.json inside Visual Studio. We recommend using CMake version 3.14 or later." 10. https://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160#enable-cmakepresetsjson-integration-in-visual-studio-2019 "If you don't want to enable CMakePresets.json integration for all CMake projects, you can enable CMakePresets.json integration for a single CMake project by adding a CMakePresets.json file to the root of the open folder. You must close and reopen the folder in Visual Studio to activate the integration. 11. https://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160#default-configure-presets ***(doesn't actually say which version..) "Default Configure Presets If no CMakePresets.json or CMakeUserPresets.json file exists, or if CMakePresets.json or CMakeUserPresets.json is invalid, Visual Studio will fall back*** on the following default Configure Presets: Windows example JSON { "name": "windows-default", "displayName": "Windows x64 Debug", "description": "Sets Ninja generator, compilers, x64 architecture, build and install directory, debug build type", "generator": "Ninja", "binaryDir": "${sourceDir}/out/build/${presetName}", "architecture": { "value": "x64", "strategy": "external" }, "cacheVariables": { "CMAKE_BUILD_TYPE": "Debug", "CMAKE_INSTALL_PREFIX": "${sourceDir}/out/install/${presetName}" }, "vendor": { "microsoft.com/VisualStudioSettings/CMake/1.0": { "hostOS": [ "Windows" ] } } }, " Signed-off-by: Philip Oakley <[email protected]>
The CMakeSettings.json file is tool generated. Developers may track it should they provide additional settings. Signed-off-by: Philip Oakley <[email protected]>
The intention of this change is to align with how the top-level git `Makefile` defines its own test target (which also internally calls `$(MAKE) -C t/ all`). This change also ensures the consistency of `make -C contrib/subtree test` with other testing in CI executions (which rely on `$DEFAULT_TEST_TARGET` being defined as `prove`). Signed-off-by: Victoria Dye <[email protected]>
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 <[email protected]>
We used to have that `make vcxproj` hack, but a hack it is. In the meantime, we have a much cleaner solution: using CMake, either explicitly, or even more conveniently via Visual Studio's built-in CMake support (simply open Git's top-level directory via File>Open>Folder...). Let's let the `README` reflect this. Signed-off-by: Johannes Schindelin <[email protected]>
This adds support for a new http.sslAutoClientCert config value. In cURL 7.77 or later the schannel backend does not automatically send client certificates from the Windows Certificate Store anymore. This config value is only used if http.sslBackend is set to "schannel", and can be used to opt in to the old behavior and force cURL to send client certificates. This fixes git-for-windows#3292 Signed-off-by: Pascal Muller <[email protected]>
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 <[email protected]>
On LLP64 systems, such as Windows, the size of `long`, `int`, etc. is only 32 bits (for backward compatibility). Git's use of `unsigned long` for file memory sizes in many places, rather than size_t, limits the handling of large files on LLP64 systems (commonly given as `>4GB`). Provide a minimum test for handling a >4GB file. The `hash-object` command, with the `--literally` and without `-w` option avoids writing the object, either loose or packed. This avoids the code paths hitting the `bigFileThreshold` config test code, the zlib code, and the pack code. Subsequent patches will walk the test's call chain, converting types to `size_t` (which is larger in LLP64 data models) where appropriate. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
The previous commit adds a test that demonstrates a problem in the `hash-object --literally` command, manifesting in an unnecessary file size limit on systems using the LLP64 data model (which includes Windows). Walking the affected code path is `cmd_hash_object()` >> `hash_fd()` >> `hash_literally()` >> `hash_object_file_literally()`. The function `hash_object_file_literally()` is the first with a file length parameter (via a mem buffer). This commit changes the type of that parameter to the LLP64 compatible `size_t` type. There are no other uses of the function. The `strbuf` type is already `size_t` compatible. Note: The hash-object test does not yet pass. Subsequent commits will continue to walk the call tree's lower level functions to identify further fixes. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Continue walking the code path for the >4GB `hash-object --literally` test. The `hash_object_file_literally()` function internally uses both `hash_object_file()` and `write_object_file_prepare()`. Both function signatures use `unsigned long` rather than `size_t` for the mem buffer sizes. Use `size_t` instead, for LLP64 compatibility. While at it, convert those function's object's header buffer length to `size_t` for consistency. The value is already upcast to `uintmax_t` for print format compatibility. Note: The hash-object test still does not pass. A subsequent commit continues to walk the call tree's lower level hash functions to identify further fixes. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Continue walking the code path for the >4GB `hash-object --literally` test to the hash algorithm step for LLP64 systems. This patch lets the SHA1DC code use `size_t`, making it compatible with LLP64 data models (as used e.g. by Windows). The interested reader of this patch will note that we adjust the signature of the `git_SHA1DCUpdate()` function without updating _any_ call site. This certainly puzzled at least one reviewer already, so here is an explanation: This function is never called directly, but always via the macro `platform_SHA1_Update`, which is usually called via the macro `git_SHA1_Update`. However, we never call `git_SHA1_Update()` directly in `struct git_hash_algo`. Instead, we call `git_hash_sha1_update()`, which is defined thusly: static void git_hash_sha1_update(git_hash_ctx *ctx, const void *data, size_t len) { git_SHA1_Update(&ctx->sha1, data, len); } i.e. it contains an implicit downcast from `size_t` to `unsigned long` (before this here patch). With this patch, there is no downcast anymore. With this patch, finally, the t1007-hash-object.sh "files over 4GB hash literally" test case is fixed. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
In Git for Windows, `has_symlinks` is set to 0 by default. Therefore, we need to parse the config setting `core.symlinks` to know if it has been set to `true`. In `git init`, we must do that before copying the templates because they might contain symbolic links. Even if the support for symbolic links on Windows has not made it to upstream Git yet, we really should make sure that all the `core.*` settings are parsed before proceeding, as they might very well change the behavior of `git init` in a way the user intended. This fixes git-for-windows#3414 Signed-off-by: Johannes Schindelin <[email protected]>
If `feature.experimental` and `feature.manyFiles` are set and the user has not explicitly turned off the builtin FSMonitor, we now start the built-in FSMonitor by default. Only forcing it when UNSET matches the behavior of UPDATE_DEFAULT_BOOL() used for other repo settings. Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Jeff Hostetler <[email protected]>
This is another fall-out of the recent refactoring flurry. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Derrick Stolee <[email protected]>
This fixes the build after 7bc341e (git-compat-util: add a test balloon for C99 support, 2021-12-01). Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
While it may seem super convenient to some old Unix hands to simpy require Perl to be available when running the test suite, this is a major hassle on Windows, where we want to verify that Perl is not, actually, required in a NO_PERL build. As a super ugly workaround, we "install" a script into /usr/bin/perl reading like this: #!/bin/sh # We'd much rather avoid requiring Perl altogether when testing # an installed Git. Oh well, that's why we cannot have nice # things. exec c:/git-sdk-64/usr/bin/perl.exe "$@" The problem with that is that BusyBox assumes that the #! line in a script refers to an executable, not to a script. So when it encounters the line #!/usr/bin/perl in t5532's proxy-get-cmd, it barfs. Let's help this situation by simply executing the Perl script with the "interpreter" specified explicitly. Signed-off-by: Johannes Schindelin <[email protected]>
When t5605 tries to verify that files are hardlinked (or that they are not), it uses the `-links` option of the `find` utility. BusyBox' implementation does not support that option, and BusyBox-w32's lstat() does not even report the number of hard links correctly (for performance reasons). So let's just switch to a different method that actually works on Windows. Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows uses MSYS2's Bash to run the test suite, which comes with benefits but also at a heavy price: on the plus side, MSYS2's POSIX emulation layer allows us to continue pretending that we are on a Unix system, e.g. use Unix paths instead of Windows ones, yet this is bought at a rather noticeable performance penalty. There *are* some more native ports of Unix shells out there, though, most notably BusyBox-w32's ash. These native ports do not use any POSIX emulation layer (or at most a *very* thin one, choosing to avoid features such as fork() that are expensive to emulate on Windows), and they use native Windows paths (usually with forward slashes instead of backslashes, which is perfectly legal in almost all use cases). And here comes the problem: with a $PWD looking like, say, C:/git-sdk-64/usr/src/git/t/trash directory.t5813-proto-disable-ssh Git's test scripts get quite a bit confused, as their assumptions have been shattered. Not only does this path contain a colon (oh no!), it also does not start with a slash. This is a problem e.g. when constructing a URL as t5813 does it: ssh://remote$PWD. Not only is it impossible to separate the "host" from the path with a $PWD as above, even prefixing $PWD by a slash won't work, as /C:/git-sdk-64/... is not a valid path. As a workaround, detect when $PWD does not start with a slash on Windows, and simply strip the drive prefix, using an obscure feature of Windows paths: if an absolute Windows path starts with a slash, it is implicitly prefixed by the drive prefix of the current directory. As we are talking about the current directory here, anyway, that strategy works. Signed-off-by: Johannes Schindelin <[email protected]>
On Windows, the current working directory is pretty much guaranteed to contain a colon. If we feed that path to CVS, it mistakes it for a separator between host and port, though. This has not been a problem so far because Git for Windows uses MSYS2's Bash using a POSIX emulation layer that also pretends that the current directory is a Unix path (at least as long as we're in a shell script). However, that is rather limiting, as Git for Windows also explores other ports of other Unix shells. One of those is BusyBox-w32's ash, which is a native port (i.e. *not* using any POSIX emulation layer, and certainly not emulating Unix paths). So let's just detect if there is a colon in $PWD and punt in that case. Signed-off-by: Johannes Schindelin <[email protected]>
The Makefile target `install-mingit-test-artifacts` simply copies stuff and things directly into a MinGit directory, including an init.bat script to set everything up so that the tests can be run in a cmd window. Sadly, Git's test suite still relies on a Perl interpreter even if compiled with NO_PERL=YesPlease. We punt for now, installing a small script into /usr/bin/perl that hands off to an existing Perl of a Git for Windows SDK. Signed-off-by: Johannes Schindelin <[email protected]>
Specify symlink type in .gitattributes
Signed-off-by: Johannes Schindelin <[email protected]>
Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>
Switch to batched fsync by default
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 <[email protected]>
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 <[email protected]>
Previously, we interpolated paths in config variables that start with a forward-slash as relative to the runtime prefix. This was not portable and has been replaced with `%(prefix)/`. Let's warn users when they use the now-deprecated form. Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
…updates Start monitoring updates of Git for Windows' component in the open
Add a README.md for GitHub goodness. Signed-off-by: Johannes Schindelin <[email protected]>
As promised, some context for the parts of the
|
Tsk, tsk. Upstream's apparently measuring with variable standards...
|
And our good old friend, t5559, failed on macos again. After some digging, I found https://lore.kernel.org/git/[email protected]/t/#u, which unfortunately seems to have fizzled without resolution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the diligent comments that really helped understand the range-diff!
/git-artifacts The Azure Pipeline run was started |
sigh The release notes look funny. There's a I think the reason for this is that a function that I overzealously removed in git-for-windows/build-extra#457 is now no longer found... But the day has been really, really long already, and I am tired, and I can fix this in time for -rc1. |
/release |
It would have been too nice if one thing worked today. |
…-note When generating the release notes of v2.40.0-rc0, I noticed in git-for-windows/git#4316 (comment) that a section was added unnecessarily. The reason is that a crucial function was removed in git-for-windows#457. The plan was to retire the entire release process based on `please.sh` and Azure Pipelines, and redo everything in git-for-windows-automation via a `tag-git` workflow, but that workflow simply is not ready yet. In preparation for those improved workflows, I already reimplemented the `sed` logic of `please.sh mention [...]` with a more straight-forward node.js script. Let's just use that script in `please.sh mention` before phasing out the functionality from `please.sh`. Signed-off-by: Johannes Schindelin <[email protected]>
This was a bit trickier than usual, as I had not merged v2.39.2.windows.1 before doing the clean-up rebase. Nothing new came in via v2.39.2.windows.1, as we merged the fixes separately. To gain confidence in the correctness of this rebase, I also performed a merge with v2.39.2.windows.1 before the rebase (which was a bit involved due to two diverging branch thickets being rebased at the same time) and verified that the result is tree-same.
Range-diff relative to `main`
1: 6956015 (upstream: 6956015) < -: ----------- http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT
2: fe7e44e (upstream: fe7e44e) < -: ----------- http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION
3: 6c065f7 (upstream: 6c065f7) < -: ----------- http: support CURLOPT_PROTOCOLS_STR
5: 5ef19b6 = 1: e413f96 windows: ignore empty
PATH
elements6: 9121f5c = 2: 68cf79e is_Cygwin: avoid
exec
ing anything7: 15ea119 = 3: d2dded9 Move is_ functions to the beginning
8: 24f3f58 = 4: 0b73b27 Move the
_which
function (almost) to the top9: 2dd8454 = 5: ce1d563 Work around Tcl's default
PATH
lookup4: 3650ca5 ! 6: 001dded gitk(Windows): avoid inadvertently calling executables in the worktree
10: f0d07dd = 7: 50124a1 t9350: point out that refs are not updated correctly
11: eaf2326 = 8: 3278034 transport-helper: add trailing --
12: 5d6481a = 9: 8179e82 remote-helper: check helper status after import/export
13: 4a9ad8b = 10: 0f7ade6 mingw: demonstrate a problem with certain absolute paths
15: d100ed4 = 11: 46bfe60 Always auto-gc after calling a fast-import transport
14: 8919340 = 12: 451c03f gitk: prevent overly long command lines
23: d737a5f = 13: a890c08 clean: do not traverse mount points
-: ----------- > 14: e60b78a mingw: include the Python parts in the build
16: bf4e3fc = 15: 67681a1 mingw: allow absolute paths without drive prefix
17: ee73ee3 = 16: 89bd56d mingw: change core.fsyncObjectFiles = 1 by default
18: ed43e86 < -: ----------- mingw: include the Python parts in the build
25: b01bd62 = 17: 16e1786 gitk: Escape file paths before piping to git log
26: 62954e1 = 18: fb1b9d9 clean: remove mount points when possible
19: 2384d02 ! 19: 1d75c6d win32/pthread: avoid name clashes with winpthread
20: 1750da6 = 20: 052cb86 git-compat-util: avoid redeclaring _DEFAULT_SOURCE
21: 65a3e96 = 21: 407d2f4 Import the source code of mimalloc v2.0.9
22: 8a69e1c = 22: e49de85 mimalloc: adjust for building inside Git
24: 4a6bd4b = 23: 5842cc5 mimalloc: offer a build-time option to enable it
-: ----------- > 24: a21daa3 mingw: use mimalloc
29: 3207284 = 25: 5e636a5 Config option to disable side-band-64k for transport
30: a9aadca = 26: 95e6e3c mingw: make sure
errno
is set correctly when socket operations fail27: 7d8228f = 27: 793a654 mingw: demonstrate a
git add
issue with NTFS junctions28: 1dd4bba < -: ----------- mingw: use mimalloc
35: 0cd3a89 = 28: f8069e7 mingw: ensure valid CTYPE
38: 59dff16 = 29: d7ac395 strbuf_realpath(): use platform-dependent API if available
37: 7ecd143 ! 30: 92f4c43 mingw: allow
git.exe
to be used instead of the "Git wrapper"31: cf8ebeb = 31: a649417 mingw: do resolve symlinks in
getcwd()
32: e0aed23 = 32: 18bacbb mingw: fix fatal error working on mapped network drives on Windows
33: 8457885 = 33: 1252989 clink.pl: fix MSVC compile script to handle libcurl-d.lib
42: c4d21fb ! 34: 99d6951 mingw: implement a platform-specific
strbuf_realpath()
34: ef56d2e = 35: 542ba94 vcxproj: unclash project directories with build outputs
36: 828c9f8 = 36: af554d2 t5505/t5516: allow running without
.git/branches/
in the templates39: 8bb50a1 = 37: 4b2aa67 t5505/t5516: fix white-space around redirectors
40: 84dac4b = 38: 45d767f mingw: ignore HOMEDRIVE/HOMEPATH if it points to Windows' system directory
41: e43973f = 39: 1a4f633 http: use new "best effort" strategy for Secure Channel revoke checking
43: 7d71411 < -: ----------- Allow
add -p
andadd -i
with a large number of files44: f6b0abd = 40: 7a30609 t3701: verify that we can add lots of files interactively
45: 485d36c = 41: 832859a git add -i: handle CR/LF line endings in the interactive input
49: 46ae884 = 42: baefe39 clink.pl: fix libexpatd.lib link error when using MSVC
50: 05efe82 = 43: 516fe05 Makefile: clean up .ilk files when MSVC=1
51: b1c486c = 44: 4c5c3f3 vcbuild: add support for compiling Windows resource files
46: a5f0bdd ! 45: fdb100c commit: accept "scissors" with CR/LF line endings
47: 7745577 = 46: 7a15315 t0014: fix indentation
48: 41735ca = 47: 991015f git-gui: accommodate for intent-to-add files
52: aa95ce2 = 48: 41d0851 config.mak.uname: add git.rc to MSVC builds
53: e243178 = 49: 50d5d34 clink.pl: ignore no-stack-protector arg on MSVC=1 builds
54: 62022ec = 50: 9350cdc clink.pl: move default linker options for MSVC=1 builds
55: 4f0ff06 = 51: 4d99259 buildsystems: remove duplicate clause
56: df6cc61 = 52: 64ef1f1 vcxproj: handle resource files, too
57: f6454e8 = 53: c807587 vcxproj: ignore -fno-stack-protector and -fno-common
58: 6677efa = 54: a32cf14 vcxproj: handle GUI programs, too
59: 640626e ! 55: 0bb2744 win32: add a helper to run
git.exe
without a foreground window61: 0139897 = 56: a0a7637 vcpkg_install: detect lack of Git
60: 15f6309 = 57: c826ba2 git maintenance: avoid console window in scheduled tasks on Windows
62: 9be5a20 = 58: 98c20fd vcpkg_install: add comment regarding slow network connections
63: 53abd5f = 59: 868cb78 vcxproj: support building Windows/ARM64 binaries
64: a22cc2b = 60: a633021 vcbuild: install ARM64 dependencies when building ARM64 binaries
65: a2f3ca0 = 61: d3d1372 vcbuild: add an option to install individual 'features'
66: 18ae03e = 62: d9ac4a4 cmake: allow building for Windows/ARM64
67: c8be050 ! 63: d03b65e ci(vs-build) also build Windows/ARM64 artifacts
68: e24188a = 64: 9415872 Add schannel to curl installation
69: 466fabf < -: ----------- Add a GitHub workflow to generate Git for Windows' Pacman package
70: bd02e76 < -: ----------- git-artifacts: if GPG secrets are available, use them
71: ab500f7 < -: ----------- git-artifacts: also code-sign, if configured via the secrets
72: 8920a9f < -: ----------- git-artifacts: also build the installer
73: f95f018 < -: ----------- git-artifacts: also build portable, mingit and mingit-busybox
74: 1517d16 < -: ----------- git-artifacts: also build 32-bit versions
75: 4dd354b < -: ----------- git-artifacts: also build the nuget package
76: 061cb59 < -: ----------- git-artifacts: allow restricting which artifacts are built
77: 1707476 < -: ----------- git-artifacts: allow specifying repo/ref via workflow_dispatch
78: 05b1547 < -: ----------- git-artifacts: cache the build-installers artifact
79: 147eaec < -: ----------- git-artifacts: use the cached build-installers instead of makepkg-git
80: ec2d71f < -: ----------- git-artifacts: add ARM64 artifacts
81: cbaf8cd < -: ----------- git-artifacts: add workaround for GCM Core on ARM64
82: 9c0c553 < -: ----------- git-artifacts(arm64): avoid hard-linking the dashed built-ins
83: bdf89f2 < -: ----------- git-artifacts: use a narrower
PATH
84: 9989dd9 < -: ----------- git-artifacts: fix BUILD_ONLY handling for ARM64
85: 52e4773 < -: ----------- git-artifacts: extend the
SKIP
logic to handlepkg
andbuild-arm64
86: da9623d < -: ----------- git-artifacts: mark all inputs as "not required"
87: 53ff636 < -: ----------- git-artifacts(build-arm64): build artifacts using the intended Git revision
88: d28652d = 65: 7cf96a2 cmake(): allow setting HOST_CPU for cross-compilation
89: e64e637 < -: ----------- git-artifacts: use the
setup-git-for-windows-sdk
Action90: 0780c6f < -: ----------- ci(): add HOST_CPU to CMake command
92: cb0861b = 66: cbb43ed ci(vs-build): download the vcpkg artifacts using a dedicated Action
93: eb73e47 = 67: 58a0bfb mingw: allow for longer paths in
parse_interpreter()
96: 1a1618b = 68: a06ca96 CMake: default Visual Studio generator has changed
97: 1438211 = 69: 737c9fe .gitignore: add Visual Studio CMakeSetting.json file
91: 838b167 = 70: e255cd7 subtree: update
contrib/subtree
test
target98: 8950f87 = 71: ebc3e45 CMakeLists: add default "x64-windows" arch for Visual Studio
94: e1fc4bb = 72: 6ce48e1 compat/vcbuild: document preferred way to build in Visual Studio
95: 84faf80 ! 73: a2aab50 http: optionally send SSL client certificate
99: 9a6f668 = 74: 3a091ba ci: run
contrib/subtree
tests in CI builds102: deb0510 = 75: 4919442 hash-object: demonstrate a >4GB/LLP64 problem
103: 8dfe78d = 76: ac14ccc hash_object_file_literally(): use size_t
104: c7254ba ! 77: 63268cf object-file.c: use size_t for header lengths
105: 659853a = 78: c150492 hash algorithms: use size_t for section lengths
106: 2f0aa65 = 79: 68413bf hash-object --stdin: verify that it works with >4GB/LLP64
107: 98e366a = 80: 69c4a51 hash-object: add another >4GB/LLP64 test case
100: 1790274 = 81: 5ac7009 CMake: show Win32 and Generator_platform build-option values
101: 0030b13 = 82: dce8708 init: do parse all core.* settings early
135: 3d55698 = 83: 0ae62eb Enable the built-in FSMonitor as an experimental feature
113: 2a5d240 = 84: dda08aa vcxproj: allow building with
NO_PERL
again108: 1d4de54 = 85: 1611c7c setup: properly use "%(prefix)/" when in WSL
114: e6d402c = 86: 9e9e178 vcxproj: require C11
109: 6ec3d44 = 87: 748e144 hash-object: add a >4GB/LLP64 test case using filtered input
110: 4474954 = 88: ff8bbbf compat/mingw.c: do not warn when failing to get owner
111: 2620f18 = 89: e3bf65b mingw: $env:TERM="xterm-256color" for newer OSes
112: 3c8df08 = 90: f8a231f winansi: check result and Buffer before using Name
122: ccc5c79 = 91: 305ccd2 Add config option
windows.appendAtomically
115: 021f02a = 92: 29cb0ce vcxproj: ignore the
-pedantic
option116: 26c6f16 = 93: 876176a vcxproj: include reftable when committing
.vcxproj
files117: 0946acb = 94: 2122c03 vcxproj: handle libreftable_test, too
118: 467b9f9 = 95: c451257 vcxproj: avoid escaping double quotes in the defines
119: 6c4f41f = 96: fb4eda6 ci: adjust Azure Pipeline for
runs_on_pool
120: d71342d = 97: 3d5698a ci: stop linking the
prove
cache121: e246b18 = 98: b536afb ci: reinstate Azure Pipelines support
123: f72ee05 = 99: 3c2b586 azure-pipeline: drop the
GETTEXT_POISON
job124: 4ba2597 = 100: 7e36c78 azure-pipeline: stop hard-coding
apt-get
calls125: 8ed8cd1 = 101: 26b80e8 azure-pipeline: drop the code to write to/read from a file share
126: caa9689 = 102: 2e28b77 azure-pipeline: use partial clone/parallel checkout to initialize minimal-sdk
127: a350114 = 103: 5ce79a5 azure-pipeline: downcase the job name of the
Linux32
job129: adc21db = 104: 9cb34f4 azure-pipeline: run static-analysis on jammy
128: a1c00e2 = 105: 3fa9bf3 bswap.h: add support for built-in bswap functions
-: ----------- > 106: c6562b1 config.mak.uname: add support for clangarm64
130: 1880cc8 = 107: 36a96ee MinGW: link as terminal server aware
131: 15b487a = 108: 52ebea4 Fix Windows version resources
132: 4a37349 < -: ----------- config.mak.uname: add support for clangarm64
133: 31274a9 = 109: 8aeff6b ci: create clangarm64-build.yml
134: 359516f = 110: a7a0d5f status: fix for old-style submodules with commondir
252: bd39815 = 111: ec040eb windows: skip linking
git-<command>
for built-ins136: 43bb1d8 = 112: fbafbb1 Win32: make FILETIME conversion functions public
137: 9f8b0dc = 113: cdc91b1 Win32: dirent.c: Move opendir down
138: 0bca34a = 114: b9f1687 mingw: make the dirent implementation pluggable
139: afbd566 = 115: 10ef2f1 Win32: make the lstat implementation pluggable
140: 623aced = 116: a6d68c8 add infrastructure for read-only file system level caches
141: 85fded9 = 117: 590c415 mingw: add a cache below mingw's lstat and dirent implementations
142: e285287 = 118: dd6dd95 fscache: load directories only once
143: 950f15a = 119: 838fac9 fscache: add key for GIT_TRACE_FSCACHE
144: deca6d1 = 120: 06da444 fscache: remember not-found directories
145: 75c2335 = 121: 832f2c4 fscache: add a test for the dir-not-found optimization
146: c5d9c03 ! 122: 2590ea3 add: use preload-index and fscache for performance
147: e036520 = 123: 177e510 dir.c: make add_excludes aware of fscache during status
148: 74ed920 = 124: 76c7ca7 fscache: make fscache_enabled() public
149: 1e39755 = 125: 6383a51 dir.c: regression fix for add_excludes with fscache
150: 5d725c2 = 126: 1411cd7 fetch-pack.c: enable fscache for stats under .git/objects
151: 64b273c = 127: d8ebf7c checkout.c: enable fscache for checkout again
152: 3fd15fa = 128: e56afbe Enable the filesystem cache (fscache) in refresh_index().
153: 4b1c5fb = 129: cf1a1b1 fscache: use FindFirstFileExW to avoid retrieving the short name
154: 0c4a155 = 130: a1f202f status: disable and free fscache at the end of the status command
155: ba64d36 = 131: 3d72754 fscache: add GIT_TEST_FSCACHE support
156: edf3ce6 = 132: f585ae3 fscache: add fscache hit statistics
157: 6970e6b = 133: cb93e53 mem_pool: add GIT_TRACE_MEMPOOL support
158: fc47d32 = 134: 194ce5a fscache: fscache takes an initial size
159: d8f4386 = 135: b9b4434 fscache: update fscache to be thread specific instead of global
160: 1e3422b = 136: 870a731 fscache: teach fscache to use mempool
161: 234a7e0 = 137: 29589f9 fscache: make fscache_enable() thread safe
162: 1a00148 = 138: f29f562 fscache: teach fscache to use NtQueryDirectoryFile
163: e525e29 = 139: 110b1db unpack-trees: enable fscache for sparse-checkout
164: ed5ee94 = 140: 2a83e87 fscache: remember the reparse tag for each entry
166: 7bc372f = 141: 030b620 fscache: implement an FSCache-aware is_mount_point()
165: 836923d = 142: 6e76118 git-gui: provide question helper for retry fallback on Windows
169: 45c0087 = 143: 5e51490 clean: make use of FSCache
167: fe8f12d = 144: 89d111c git gui: set GIT_ASKPASS=git-gui--askpass if not set yet
170: 933f6c1 = 145: e5c5ac7 gitk: Unicode file name support
171: 3c133e6 = 146: b95f801 git-gui--askyesno: fix funny text wrapping
172: d6f2f98 = 147: c0c6c2a gitk: Use an external icon file on Windows
173: 2e4243c = 148: 8d5cc8e git-gui--askyesno: allow overriding the window title
174: 3fc5d98 = 149: 5808618 gitk: fix arrow keys in input fields with Tcl/Tk >= 8.6
168: 6d64ce8 = 150: 06b42d8 respect core.hooksPath, falling back to .git/hooks
175: 19879b6 = 151: 8d906a4 git-gui--askyesno (mingw): use Git for Windows' icon, if available
176: 587c47f = 152: 5241c7e gitk: make the "list references" default window width wider
177: da7bca8 = 153: 7b6c5d9 pack-objects (mingw): demonstrate a segmentation fault with large deltas
178: 5995cba = 154: 0f25ae5 mingw: support long paths
179: ba2f2c4 = 155: bb474ad Win32: fix 'lstat("dir/")' with long paths
181: 3e483a6 = 156: 3c5c5fa mingw: Support
git_terminal_prompt
with more terminals182: 44d9d9f = 157: 72effe8 compat/terminal.c: only use the Windows console if bash 'read -r' fails
183: 311d8d0 = 158: 67c8d85 mingw (git_terminal_prompt): do fall back to CONIN$/CONOUT$ method
184: 539acfd ! 159: 614440c Unbreak interactive GPG prompt upon signing
180: 80ab703 = 160: cd1ebc6 compat/fsmonitor/fsm-*-win32: support long paths
191: d5c0285 = 161: 84676a0 clean: suggest using
core.longPaths
if paths are too long to remove185: 03adaa8 = 162: 97e1a08 strbuf_readlink: don't call readlink twice if hint is the exact link size
186: a11eb0d = 163: faee3cc strbuf_readlink: support link targets that exceed PATH_MAX
187: 084ed40 = 164: 8927035 lockfile.c: use is_dir_sep() instead of hardcoded '/' checks
188: 9cb15a3 = 165: 729f0f5 Win32: don't call GetFileAttributes twice in mingw_lstat()
189: 26fc0b4 = 166: 5948c42 Win32: implement stat() with symlink support
190: a637541 = 167: 10f65c6 Win32: remove separate do_lstat() function
192: 96ce0e1 = 168: 4542a6d Win32: let mingw_lstat() error early upon problems with reparse points
193: e8e484c = 169: f162aab mingw: teach fscache and dirent about symlinks
194: e35db5b = 170: 3d6455d Win32: lstat(): return adequate stat.st_size for symlinks
195: 73a0727 = 171: 8e068d6 Win32: factor out retry logic
196: fb5c212 = 172: cb64004 Win32: change default of 'core.symlinks' to false
197: 002f6d7 = 173: 7d73cae Win32: add symlink-specific error codes
198: 2b6edaa = 174: 72cf36c Win32: mingw_unlink: support symlinks to directories
199: 3e2fdc7 = 175: 4b357ff Win32: mingw_rename: support renaming symlinks
200: 8a5ac3a = 176: 73ae84f Win32: mingw_chdir: change to symlink-resolved directory
201: a55b000 = 177: 4779090 Win32: implement readlink()
202: 3226ff0 = 178: 83af0b6 mingw: lstat: compute correct size for symlinks
203: cbf7745 = 179: be02bf9 Win32: implement basic symlink() functionality (file symlinks only)
204: 2856604 = 180: 0d2ea31 Win32: symlink: add support for symlinks to directories
205: fa9702d = 181: 5ec3d20 mingw: try to create symlinks without elevated permissions
206: 4369bd4 = 182: baf2818 mingw: emulate stat() a little more faithfully
207: df92415 = 183: d639aa8 mingw: special-case index entries for symlinks with buggy size
208: 4b8f4ae = 184: 0ee652b mingw: introduce code to detect whether we're inside a Windows container
209: 9d9d80e = 185: 42ab733 mingw: when running in a Windows container, try to rename() harder
211: c0c4706 = 186: c222e88 mingw: move the file_attr_to_st_mode() function definition
210: 84e5a02 = 187: e623bdc Win32: symlink: move phantom symlink creation to a separate function
213: 239543f = 188: 62ae7a2 mingw: Windows Docker volumes are not symbolic links
212: 6c11ac4 = 189: d67da81 Introduce helper to create symlinks that knows about index_state
235: efb3a9b = 190: e59bd08 mingw: kill child processes in a gentler way
238: d4e159a = 191: 11819ad mingw: really handle SIGINT
236: 2e61c1f = 192: b14858c mingw: do not call xutftowcs_path in mingw_mktemp
239: ca885de = 193: bca7a33 Partially un-revert "editor: save and reset terminal after calling EDITOR"
244: b5b95ce ! 194: 893bb04 reset: reinstate support for the deprecated --stdin option
245: 0f78da5 = 195: 707c60a mingw: deprecate old-style runtime-prefix handling in interpolate_path()
246: b1bdd6b = 196: 4735523 fsmonitor: reintroduce core.useBuiltinFSMonitor
256: 273932a = 197: 35c8dc6 Describe Git for Windows' architecture [no ci]
240: d6131d2 = 198: 8d15bd6 Modify the Code of Conduct for Git for Windows
241: d086752 = 199: 2abe5b2 CONTRIBUTING.md: add guide for first-time contributors
242: 3a7e719 = 200: 29cf512 README.md: Add a Windows-specific preamble
243: 28ac952 = 201: 729a7d9 Add an issue template
248: bf6c6f4 = 202: 2096e07 Modify the GitHub Pull Request template (to reflect Git for Windows)
249: 759d37b = 203: bc82078 .github: Add configuration for the Sentiment Bot
250: a927b40 = 204: d14b410 Document how $HOME is set on Windows
247: 085cf01 = 205: 9d3ca5b Add a GitHub workflow to monitor component updates
251: ce6fcec = 206: 4e7f5f2 SECURITY.md: document Git for Windows' policies
214: cddc8a8 ! 207: 0fc73a0 mingw: allow to specify the symlink type in .gitattributes
215: 0606eec = 208: 6e2155a Win32: symlink: add test for
symlink
attribute216: c143846 ! 209: 9dd0601 mingw: explicitly specify with which cmd to prefix the cmdline
217: 8440580 = 210: 68a14c2 mingw: when path_lookup() failed, try BusyBox
218: 4d445c4 = 211: c79f9e6 test-lib: avoid unnecessary Perl invocation
219: 8e5c208 (upstream: a3795bf) < -: ----------- tests: replace mingw_test_cmp with a helper in C
220: f334bd9 = 212: 9b1ec0d test-tool: learn to act as a drop-in replacement for
iconv
221: 70b9491 ! 213: c7a9d71 tests(mingw): if
iconv
is unavailable, usetest-helper --iconv
222: be45541 < -: ----------- gitattributes: mark .png files as binary
-: ----------- > 214: ad9eb8a gitattributes: mark .png files as binary
223: 2dde788 ! 215: 4498773 tests: move test PNGs into t/lib-diff/
224: deccf1f = 216: f8707a4 tests: only override sort & find if there are usable ones in /usr/bin/
225: 11f9940 ! 217: abf8f1c tests: use the correct path separator with BusyBox
226: beadc99 = 218: a847885 mingw: only use Bash-ism
builtin pwd -W
when available227: 8cd2f40 = 219: 26b04f6 tests (mingw): remove Bash-specific pwd option
228: e0370b7 = 220: 4841293 test-lib: add BUSYBOX prerequisite
229: a38a7e1 (upstream: 95494c6) < -: ----------- t0021: use Windows path when appropriate
230: 6db1cfa = 221: a897ddf t5003: use binary file from t/lib-diff/
231: ebd57d1 = 222: 42cb115 t5532: workaround for BusyBox on Windows
232: 6dc5f44 = 223: b04c40f t5605: special-case hardlink test for BusyBox-w32
233: 45766ce = 224: 71587f9 t5813: allow for $PWD to be a Windows path
234: 739046c = 225: 39c301c t9200: skip tests when $PWD contains a colon
237: 77fb97b ! 226: 3bfb04c mingw: add a Makefile target to copy test artifacts
253: 622f956 < -: ----------- fixup! mingw: implement a platform-specific
strbuf_realpath()
254: b9457d6 < -: ----------- fixup! mingw: implement a platform-specific
strbuf_realpath()
255: e1584e4 < -: ----------- git-artifacts: remove workflow
There is quite a bit of extra context to unpack here, and to avoid running into character count limitations, I will do that in a follow-up comment.