Rebase shears/next: 1 conflict(s) (0 skipped, 1 resolved) (#24060601926)#97
Open
gitforwindowshelper[bot] wants to merge 281 commits intobase/shears/next-24060601926from
Open
Rebase shears/next: 1 conflict(s) (0 skipped, 1 resolved) (#24060601926)#97gitforwindowshelper[bot] wants to merge 281 commits intobase/shears/next-24060601926from
gitforwindowshelper[bot] wants to merge 281 commits intobase/shears/next-24060601926from
Conversation
Signed-off-by: Derrick Stolee <[email protected]>
Windows' equivalent to "bind mounts", NTFS junction points, can be unlinked without affecting the mount target. This is clearly what users expect to happen when they call `git clean -dfx` in a worktree that contains NTFS junction points: the junction should be removed, and the target directory of said junction should be left alone (unless it is inside the worktree). Signed-off-by: Johannes Schindelin <[email protected]>
While Git for Windows does not _ship_ Python (in order to save on bandwidth), MSYS2 provides very fine Python interpreters that users can easily take advantage of, by using Git for Windows within its SDK. Signed-off-by: Johannes Schindelin <[email protected]>
Thorough benchmarking with repacking a subset of linux.git (the commit history reachable from 93a6fef ([PATCH] fix the SYSCTL=n compilation, 2007-02-28), to be precise) suggest that this allocator is on par, in multi-threaded situations maybe even better than nedmalloc: `git repack -adfq` with mimalloc, 8 threads: 31.166991900 27.576763800 28.712311000 27.373859000 27.163141900 `git repack -adfq` with nedmalloc, 8 threads: 31.915032900 27.149883100 28.244933700 27.240188800 28.580849500 In a different test using GitHub Actions build agents (probably single-threaded, a core-strength of nedmalloc)): `git repack -q -d -l -A --unpack-unreachable=2.weeks.ago` with mimalloc: 943.426 978.500 939.709 959.811 954.605 `git repack -q -d -l -A --unpack-unreachable=2.weeks.ago` with nedmalloc: 995.383 952.179 943.253 963.043 980.468 While these measurements were not executed with complete scientific rigor, as no hardware was set aside specifically for these benchmarks, it shows that mimalloc and nedmalloc perform almost the same, nedmalloc with a bit higher variance and also slightly higher average (further testing suggests that nedmalloc performs worse in multi-threaded situations than in single-threaded ones). In short: mimalloc seems to be slightly better suited for our purposes than nedmalloc. Seeing that mimalloc is developed actively, while nedmalloc ceased to see any updates in eight years, let's use mimalloc on Windows instead. Signed-off-by: Johannes Schindelin <[email protected]>
Since commit 0c499ea (send-pack: demultiplex a sideband stream with status data, 2010-02-05) the send-pack builtin uses the side-band-64k capability if advertised by the server. Unfortunately this breaks pushing over the dump git protocol if used over a network connection. The detailed reasons for this breakage are (by courtesy of Jeff Preshing, quoted from https://groups.google.com/d/msg/msysgit/at8D7J-h7mw/eaLujILGUWoJ): MinGW wraps Windows sockets in CRT file descriptors in order to mimic the functionality of POSIX sockets. This causes msvcrt.dll to treat sockets as Installable File System (IFS) handles, calling ReadFile, WriteFile, DuplicateHandle and CloseHandle on them. This approach works well in simple cases on recent versions of Windows, but does not support all usage patterns. In particular, using this approach, any attempt to read & write concurrently on the same socket (from one or more processes) will deadlock in a scenario where the read waits for a response from the server which is only invoked after the write. This is what send_pack currently attempts to do in the use_sideband codepath. The new config option `sendpack.sideband` allows to override the side-band-64k capability of the server, and thus makes the dumb git protocol work. Other transportation methods like ssh and http/https still benefit from the sideband channel, therefore the default value of `sendpack.sideband` is still true. Signed-off-by: Thomas Braun <[email protected]> Signed-off-by: Oliver Schneider <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
In 1e64d18 (mingw: do resolve symlinks in `getcwd()`) a problem was introduced that causes git for Windows to stop working with certain mapped network drives (in particular, drives that are mapped to locations with long path names). Error message was "fatal: Unable to read current working directory: No such file or directory". Present change fixes this issue as discussed in git-for-windows#2480 Signed-off-by: Bjoern Mueller <[email protected]>
Update clink.pl to link with either libcurl.lib or libcurl-d.lib depending on whether DEBUG=1 is set. Signed-off-by: Jeff Hostetler <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
There is a Win32 API function to resolve symbolic links, and we can use that instead of resolving them manually. Even better, this function also resolves NTFS junction points (which are somewhat similar to bind mounts). This fixes git-for-windows#2481. Signed-off-by: Johannes Schindelin <[email protected]>
The native Windows HTTPS backend is based on Secure Channel which lets the caller decide how to handle revocation checking problems caused by missing information in the certificate or offline CRL distribution points. Unfortunately, cURL chose to handle these problems differently than OpenSSL by default: while OpenSSL happily ignores those problems (essentially saying "¯\_(ツ)_/¯"), the Secure Channel backend will error out instead. As a remedy, the "no revoke" mode was introduced, which turns off revocation checking altogether. This is a bit heavy-handed. We support this via the `http.schannelCheckRevoke` setting. In curl/curl#4981, we contributed an opt-in "best effort" strategy that emulates what OpenSSL seems to do. In Git for Windows, we actually want this to be the default. This patch makes it so, introducing it as a new value for the `http.schannelCheckRevoke" setting, which now becmes a tristate: it accepts the values "false", "true" or "best-effort" (defaulting to the last one). Signed-off-by: Johannes Schindelin <[email protected]>
The convention in Git project's shell scripts is to have white-space _before_, but not _after_ the `>` (or `<`). Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
This change enhances `git commit --cleanup=scissors` by detecting scissors lines ending in either LF (UNIX-style) or CR/LF (DOS-style). Regression tests are included to specifically test for trailing comments after a CR/LF-terminated scissors line. Signed-off-by: Luke Bonanomi <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
For some reason, this test case was indented with 4 spaces instead of 1 horizontal tab. The other test cases in the same test script are fine. Signed-off-by: Jens Glathe <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
As of Git v2.28.0, the diff for files staged via `git add -N` marks them as new files. Git GUI was ill-prepared for that, and this patch teaches Git GUI about them. Please note that this will not even fix things with v2.28.0, as the `rp/apply-cached-with-i-t-a` patches are required on Git's side, too. This fixes git-for-windows#2779 Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Pratyush Yadav <[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]>
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]>
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]>
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]>
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]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: 孙卓识 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[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]>
With improvements by Clive Chan, Adric Norris, Ben Bodenmiller and Philip Oakley. Helped-by: Clive Chan <[email protected]> Helped-by: Adric Norris <[email protected]> Helped-by: Ben Bodenmiller <[email protected]> Helped-by: Philip Oakley <[email protected]> Signed-off-by: Brendan Forster <[email protected]> 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]>
The TerminateProcess() function does not actually leave the child processes any chance to perform any cleanup operations. This is bad insofar as Git itself expects its signal handlers to run. A symptom is e.g. a left-behind .lock file that would not be left behind if the same operation was run, say, on Linux. To remedy this situation, we use an obscure trick: we inject a thread into the process that needs to be killed and to let that thread run the ExitProcess() function with the desired exit status. Thanks J Wyman for describing this trick. The advantage is that the ExitProcess() function lets the atexit handlers run. While this is still different from what Git expects (i.e. running a signal handler), in practice Git sets up signal handlers and atexit handlers that call the same code to clean up after itself. In case that the gentle method to terminate the process failed, we still fall back to calling TerminateProcess(), but in that case we now also make sure that processes spawned by the spawned process are terminated; TerminateProcess() does not give the spawned process a chance to do so itself. Please note that this change only affects how Git for Windows tries to terminate processes spawned by Git's own executables. Third-party software that *calls* Git and wants to terminate it *still* need to make sure to imitate this gentle method, otherwise this patch will not have any effect. Signed-off-by: Johannes Schindelin <[email protected]>
Rather than using private IFTTT Applets that send mails to this maintainer whenever a new version of a Git for Windows component was released, let's use the power of GitHub workflows to make this process publicly visible. This workflow monitors the Atom/RSS feeds, and opens a ticket whenever a new version was released. Note: Bash sometimes releases multiple patched versions within a few minutes of each other (i.e. 5.1p1 through 5.1p4, 5.0p15 and 5.0p16). The MSYS2 runtime also has a similar system. We can address those patches as a group, so we shouldn't get multiple issues about them. Note further: We're not acting on newlib releases, OpenSSL alphas, Perl release candidates or non-stable Perl releases. There's no need to open issues about them. Co-authored-by: Matthias Aßhauer <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows accepts pull requests; Core Git does not. Therefore we need to adjust the template (because it only matches core Git's project management style, not ours). Also: direct Git for Windows enhancements to their contributions page, space out the text for easy reading, and clarify that the mailing list is plain text, not HTML. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
These are Git for Windows' Git GUI and gitk patches. We will have to decide at some point what to do about them, but that's a little lower priority (as Git GUI seems to be unmaintained for the time being, and the gitk maintainer keeps a very low profile on the Git mailing list, too). 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 Windows Subsystem for Linux (WSL) version 2 allows to use `chmod` on NTFS volumes provided that they are mounted with metadata enabled (see https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/ for details), for example: $ chmod 0755 /mnt/d/test/a.sh In order to facilitate better collaboration between the Windows version of Git and the WSL version of Git, we can make the Windows version of Git also support reading and writing NTFS file modes in a manner compatible with WSL. Since this slightly slows down operations where lots of files are created (such as an initial checkout), this feature is only enabled when `core.WSLCompat` is set to true. Note that you also have to set `core.fileMode=true` in repositories that have been initialized without enabling WSL compatibility. There are several ways to enable metadata loading for NTFS volumes in WSL, one of which is to modify `/etc/wsl.conf` by adding: ``` [automount] enabled = true options = "metadata,umask=027,fmask=117" ``` And reboot WSL. It can also be enabled temporarily by this incantation: $ sudo umount /mnt/c && sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=111 It's important to note that this modification is compatible with, but does not depend on WSL. The helper functions in this commit can operate independently and functions normally on devices where WSL is not installed or properly configured. Signed-off-by: xungeng li <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Previously, we did not install any handler for Ctrl+C, but now we really want to because the MSYS2 runtime learned the trick to call the ConsoleCtrlHandler when Ctrl+C was pressed. With this, hitting Ctrl+C while `git log` is running will only terminate the Git process, but not the pager. This finally matches the behavior on Linux and on macOS. Signed-off-by: Johannes Schindelin <[email protected]>
…ITOR" In e3f7e01 (Revert "editor: save and reset terminal after calling EDITOR", 2021-11-22), we reverted the commit wholesale where the terminal state would be saved and restored before/after calling an editor. The reverted commit was intended to fix a problem with Windows Terminal where simply calling `vi` would cause problems afterwards. To fix the problem addressed by the revert, but _still_ keep the problem with Windows Terminal fixed, let's revert the revert, with a twist: we restrict the save/restore _specifically_ to the case where `vi` (or `vim`) is called, and do not do the same for any other editor. This should still catch the majority of the cases, and will bridge the time until the original patch is re-done in a way that addresses all concerns. Signed-off-by: Johannes Schindelin <[email protected]>
The `--stdin` option was a well-established paradigm in other commands, therefore we implemented it in `git reset` for use by Visual Studio. Unfortunately, upstream Git decided that it is time to introduce `--pathspec-from-file` instead. To keep backwards-compatibility for some grace period, we therefore reinstate the `--stdin` option on top of the `--pathspec-from-file` option, but mark it firmly as deprecated. Helped-by: Victoria Dye <[email protected]> Helped-by: Matthew John Cheetham <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Reintroduce the 'core.useBuiltinFSMonitor' config setting (originally added in 0a756b2 (fsmonitor: config settings are repository-specific, 2021-03-05)) after its removal from the upstream version of FSMonitor. Upstream, the 'core.useBuiltinFSMonitor' setting was rendered obsolete by "overloading" the 'core.fsmonitor' setting to take a boolean value. However, several applications (e.g., 'scalar') utilize the original config setting, so it should be preserved for a deprecation period before complete removal: * if 'core.fsmonitor' is a boolean, the user is correctly using the new config syntax; do not use 'core.useBuiltinFSMonitor'. * if 'core.fsmonitor' is unspecified, use 'core.useBuiltinFSMonitor'. * if 'core.fsmonitor' is a path, override and use the builtin FSMonitor if 'core.useBuiltinFSMonitor' is 'true'; otherwise, use the FSMonitor hook indicated by the path. Additionally, for this deprecation period, advise users to switch to using 'core.fsmonitor' to specify their use of the builtin FSMonitor. Signed-off-by: Victoria Dye <[email protected]>
See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot#enabling-dependabot-version-updates-for-actions for details. Signed-off-by: Johannes Schindelin <[email protected]>
This is the recommended way on GitHub to describe policies revolving around security issues and about supported versions. Helped-by: Sven Strickroth <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
This was pull request git-for-windows#1645 from ZCube/master Support windows container. Signed-off-by: Johannes Schindelin <[email protected]>
…ws#4527) With this patch, Git for Windows works as intended on mounted APFS volumes (where renaming read-only files would fail). Signed-off-by: Johannes Schindelin <[email protected]>
Specify symlink type in .gitattributes
Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>
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]>
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]>
git-for-windows@1edeb9a (Win32: warn if the console font doesn't support Unicode, 2014-06-10) introduced both code to detect the current console font on Windows Vista and newer and a fallback for older systems to detect the default console font and issue a warning if that font doesn't support unicode. Since we haven't supported any Windows older than Vista in almost a decade, we don't need to keep the workaround. This more or less fell out of git-for-windows#6108, but didn't quite fit into that PR. There are also some other version specific hacks and workarounds I considered dropping, but decided against: * git-for-windows@492f709 * I'm unsure if this regression has ever been fixed or just become the new normal. * git-for-windows#5042 * So far this hasn't been an issue on Windows 8.1, but officially Go 1.21 and newer only support Windows 10 and newer. So this might become a problem at any point.
…s#6108) While the currently used way to detect the number of CPU cores ond Windows is nice and straight-forward, GetSystemInfo() only [gives us access to the number of processors within the current group.](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members) While that is usually fine for systems with a single physical CPU, separate physical sockets are typically separate groups. Switch to using GetLogicalProcessorInformationEx() to handle multi-socket systems better. I've tested this on a physical single-socket x86-64 and a physical dual-socket x86-64 system, and on a virtual single-socket ARM64 system. Physical [multi-socket ARM64 systems seem to exist](https://cloudbase.it/ampere-altra-industry-leading-arm64-server/), but I don't have access to such hardware and the hypervisor I use apparently can't emulate that either.
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: 123993c16f (Detect number of cores better on multi-socket systems (git-for-windows#6108), 2026-04-06) (e638cb8d93..123993c16f)
Resolved: 5933db9e9c (Winansi: Drop pre-Vista workaround (git-for-windows#6109), 2026-04-06)
resolved all 8 conflicting files by taking HEAD (ours) version; the merge commit had no downstream changes to these files (diff from parent 1 was empty)
Range-diff
1: 5933db9e9c ! 1: 82b5fb0 Winansi: Drop pre-Vista workaround (Winansi: Drop pre-Vista workaround git#6109)
@@ Metadata ## Commit message ## Winansi: Drop pre-Vista workaround (#6109) - https://github.com/git-for-windows/git/commit/1edeb9abf5828e317999b4ebe8b7472c494341f2 (Win32: warn if the console font doesn't support Unicode, 2014-06-10) introduced both code to detect the current console font on @@ Commit message * So far this hasn't been an issue on Windows 8.1, but officially Go 1.21 and newer only support Windows 10 and newer. So this might become a problem at any point. + + ## Documentation/config/sideband.adoc ## + remerge CONFLICT (add/add): Merge conflict in Documentation/config/sideband.adoc + index 39466de40e..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 +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 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. +--- +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + + ## builtin/reset.c ## + remerge CONFLICT (content): Merge conflict in builtin/reset.c + index bc51227cf1..1cd7e61fe4 100644 + --- builtin/reset.c + +++ builtin/reset.c +@@ builtin/reset.c: int cmd_reset(int argc, + struct object_id oid; + struct pathspec pathspec; + int intent_to_add = 0; +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + struct interactive_options interactive_opts = INTERACTIVE_OPTIONS_INIT; +-======= +- struct add_p_opt add_p_opt = ADD_P_OPT_INIT; +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + int nul_term_line = 0, read_from_stdin = 0; + const struct option options[] = { + OPT__QUIET(&quiet, N_("be quiet, only report errors")), + + ## git-curl-compat.h ## + remerge CONFLICT (content): Merge conflict in git-curl-compat.h + index d451497253..5c8ceb076a 100644 + --- git-curl-compat.h + +++ git-curl-compat.h +@@ + #endif + + /** +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + * CURLINFO_RETRY_AFTER was added in 7.66.0, released in September 2019. + * It allows curl to automatically parse Retry-After headers. + */ +@@ + #endif + + /** +-======= +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + * CURLSSLOPT_AUTO_CLIENT_CERT was added in 7.77.0, released in May + * 2021. + */ + + ## http.c ## + remerge CONFLICT (content): Merge conflict in http.c + index f3b03550ea..54cbf8ed7a 100644 + --- http.c + +++ http.c +@@ http.c: static long http_schannel_check_revoke_mode = + CURLSSLOPT_NO_REVOKE; + #endif + +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + static long http_retry_after = 0; + static long http_max_retries = 0; + static long http_max_retry_time = 300; + +-======= +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + /* + * With the backend being set to `schannel`, setting sslCAinfo would override + * the Certificate Store in cURL v7.60.0 and later, which is not what we want + + ## refs/reftable-backend.c ## + remerge CONFLICT (content): Merge conflict in refs/reftable-backend.c + index c86760375d..2f438385da 100644 + --- refs/reftable-backend.c + +++ refs/reftable-backend.c +@@ refs/reftable-backend.c: static struct ref_store *reftable_be_init(struct repository *repo, + umask(mask); + + reftable_set_alloc(malloc, realloc, free); +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + + refs_compute_filesystem_location(gitdir, payload, &is_worktree, &refdir, + &ref_common_dir); + + base_ref_store_init(&refs->base, repo, refdir.buf, &refs_be_reftable); +-======= +- base_ref_store_init(&refs->base, repo, gitdir, &refs_be_reftable); +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + strmap_init(&refs->worktree_backends); + refs->store_flags = store_flags; + refs->log_all_ref_updates = repo_settings_get_log_all_ref_updates(repo); + + ## sideband.c ## + remerge CONFLICT (content): Merge conflict in sideband.c + index 3b453387ae..c6a3c00115 100644 + --- sideband.c + +++ sideband.c +@@ sideband.c: static struct keyword_entry keywords[] = { + }; + + static enum { +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 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; +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + + /* 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; + +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 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 */ +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + } + + 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); + } + +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 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) +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + { + 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 +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + * + * 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') { +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + 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; + +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) { +-======= +- if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) { +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + strbuf_add(dest, src, n); + return; + } + + strbuf_grow(dest, n); + for (; n && *src; src++, n--) { +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 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))) { +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + src += i; + n -= i; + } else { + strbuf_addch(dest, '^'); +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src); +-======= +- strbuf_addch(dest, 0x40 + *src); +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + } + } + } + + ## t/meson.build ## + remerge CONFLICT (content): Merge conflict in t/meson.build + index 4191b382fa..81591f64bf 100644 + --- t/meson.build + +++ t/meson.build +@@ t/meson.build: integration_tests = [ + 't7422-submodule-output.sh', + 't7423-submodule-symlinks.sh', + 't7424-submodule-mixed-ref-formats.sh', +-<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 't7425-submodule-gitdir-path-extension.sh', + 't7426-submodule-get-default-remote.sh', +-======= +->>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + 't7429-submodule-long-path.sh', + 't7450-bad-git-dotfiles.sh', + 't7500-commit-template-squash-signoff.sh', + + ## t/t5409-colorize-remote-messages.sh ## + remerge CONFLICT (content): Merge conflict in t/t5409-colorize-remote-messages.sh + index 588075eb1d..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 +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + test_config_global uploadPack.packObjectsHook ./color-me-surprised && +-================================ +- test_config_global uploadPack.packObjectshook ./color-me-surprised && +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + 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 + ' + +-<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 7aca03957b (Merge 'readme' into HEAD) + 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 + ' + +-================================ +->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 44760f1bb6 (compat/winansi: drop pre-Vista workaround) + test_doneTo: 6070036518 (Detect number of cores better on multi-socket systems (git-for-windows#6108), 2026-04-06) (91ea4ebc03..6070036518)
Statistics
Range-diff (click to expand)
^$false match at end of filegit addissue with NTFS junctions.git/branches/in the templatescontrib/subtreetesttargetwindows.appendAtomicallystrbuf_realpath()parse_interpreter()contrib/subtreetests in CI buildsgit-<command>for built-insCC = gcc--pic-executableETC_*for MSYS2 environmentsgit.exeto be used instead of the "Git wrapper"errnois set correctly when socket operations failwindows.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-junctionparse_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 available