Rebase to Cygwin/MSYS2 runtime v3.5.6 #84
Merged
Conversation
This file contains 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
Signed-off-by: Corinna Vinschen <[email protected]>
After commit a0933cd17d19, access(_, X_OK) returns 0 if the user
holds SE_BACKUP_PRIVILEGE, even if the file's ACL denies execution
to the user. This is triggered by trying to open the file with
FILE_OPEN_FOR_BACKUP_INTENT.
Fix check_file_access() so it checks for X_OK without specifying
the FILE_OPEN_FOR_BACKUP_INTENT flag if the file is not a directory.
Rearrange function slightly and add comments for easier comprehension.
Fixes: a0933cd17d19 ("Cygwin: access: Correction for samba/SMB share")
Reported-by: Bruno Haible <[email protected]>
Co-authored-by: Takashi Yano <[email protected]>
Signed-off-by: Corinna Vinschen <[email protected]>
(cherry picked from commit 2e4db338ac125579d555aeee516e48588a628a16)
unlink_nt() and rename2 () both check for the FILE_SUPPORTS_OPEN_BY_FILE_ID flag to use POSIX delete/rename semantics. Both erroneously check the flag against the file attributes using has_attributes(). Given that this flag is a filesystem flag, check using fs_flags() instead. Fixes: fe2545e ("Cygwin: don't use unlink/rename POSIX semantics on certain NTFS") Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit 264544bf72f6ed85530a1b058e9efdb73ab72e90)
This FAQ entry has been commented out for quite some time. Drop it. Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit 37ed066c5f76d179c83342a816d72f996a8af3d2)
When Microsoft started to claim the "sshd" service name, we had to rename our service to "cygsshd" but we never updated the docs. Make sure the docs reflect the changed service name and fix a few bumpy expression. Reported-by: Mario Emmenlauer <[email protected]> Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit d21eb90bbcadb30a00abf59dd64375601c108f96)
Use "Cygwin Setup program" and add a link to the homepage in some cases. Reported-by: David Dyck <[email protected]> Reviewed-by: Jon Turney <[email protected]> Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit 4adb6c380659c6f74f7971ceb93c82558331f74a)
To allow cygwait() to be called in the signal handler, a locally created timer is used instead of _cygtls::locals.cw_timer if it is in use. Co-Authored-By: Corinna Vinschen <[email protected]> Signed-off-by: Takashi Yano <[email protected]> (cherry picked from commit ea1914000adcbed5c16fc0ba2676173b2f6016c4)
The commit a22a0ad7c4f0 was not entirely correct. Even with the patch, some hangs still occur. This patch overrides the previous commit along with the patch that makes cygwait() reentrant, to fix these hangs. Addresses: https://cygwin.com/pipermail/cygwin/2024-December/256954.html Fixes: d243e51ef1d3 ("Cygwin: signal: Fix deadlock between main thread and sig thread") Reported-by: Daisuke Fujimura <[email protected]> Reviewed-by: Corinna Vinschen <[email protected]> Signed-off-by: Takashi Yano <[email protected]> (cherry picked from commit 83afe3e238cd12fb7d4799ba6b3c77e9e3618d91)
Validate the fd returned by cygheap_getfd operating on given mqd. A release note is provided for 3.5.6. Reported-by: Christian Franke <[email protected]> Addresses: https://cygwin.com/pipermail/cygwin/2025-January/257090.html Signed-off-by: Mark Geisert <[email protected]> Fixes: 46f3b0c (Cygwin: POSIX msg queues: move all mq_* functionality into fhandler_mqueue) (cherry picked from commit 9a4a44523bb71e1fd453cdebe2182c9ab913a222)
Signed-off-by: Takashi Yano <[email protected]>
It seems that current _cygtls::handle_SIGCONT() code sometimes falls
into a deadlock due to frequent TLS lock/unlock operation in the
yield() loop. With this patch, the yield() in the wait loop is placed
outside the TLS lock to avoid frequent TLS lock/unlock.
Fixes: 9ae51bcc51a7 ("Cygwin: signal: Fix another deadlock between main and sig thread")
Reviewed-by: Corinna Vinschen <[email protected]>
Signed-off-by: Takashi Yano <[email protected]>
Commentary wording now refers to tasks (i.e., threads) rather than processes. This makes it somewhat easier to justify adding two kinds of counters together. After researching what "load average" has meant over time, we have what seems like a reasonable implementation, modulo Windows differences to Linux. The best resource I found is: https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html At end of load_init(), obtain and discard the first measure of the counters to deal with the first call always returning error, no data. Follow this with a specific short delay so the next measure actually has data to report. At least one older version of Windows, i.e. Win10 Pro 21H1, has a different name/location for the '% Processor Time' counter and is missing the 'Processor Queue Length' counter entirely. Code is changed to support both possible locations of the former and treat the missing latter as always reporting 0.0. A release note is added for 3.5.6. Reported-by: Mark Liam Brown <[email protected]> Addresses: https://cygwin.com/pipermail/cygwin/2024-August/256361.html Signed-off-by: Mark Geisert <[email protected]> Fixes: 4dc982ddf60b (Cygwin: loadavg: improve debugging of load_init) (cherry picked from commit 0135b94949d2c9ba0b0f839fae8ff49a5bfe8589)
(cherry picked from commit ca22984cc4ad720d186797dcd8aafa295bc7fde1)
The debug statement supposed to be printed when deleting with POSIX semantics failed with STATUS_CANNOT_DELETE or STATUS_INVALID_PARAMETER is in the wrong spot. While at it, simplify the related comment. Fixes: 9fa22db ("Cygwin: unlink: allow fallback from POSIX to default method") Fixes: 527dd1b ("Cygwin: fix unlink in container") Fixes: 87ab6c7 ("Cygwin: log disabling posix semantics") Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit bf94b87f54de862a1c2482d411a18973b29264fe)
This simplifies further checks for on-disk-devices in places with special handling for such files. Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit d870655f570f25393dcefbaf0b1dc807f277749c)
Some checks in path_conv are checking for various properties to generate a boolean value, mostly to indicate different combinations of on-disk files and devices. Simplify these checks and, especially, document them inline. Drop the isdevice() check in favor of a new isondisk() check. Fixes: 4fc922b ("Cygwin: POSIX msg queues: Convert mqd_t to a descriptor") Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit 890086ad3704fc1aaedca96d3bf67448e7a66775)
Checking EPERM only makes sense if the file exists, so let the EEXIST check change places with the EPERM check. Add a debug statement to the EPERM condition. Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit b879cd1661ad2fb37f603e18f6b1860c91f445ec)
Signed-off-by: Corinna Vinschen <[email protected]> (cherry picked from commit df63cbfedd1202b0f404a050358b258662cc0770)
Cygwin's speclib doesn't handle dashes or dots. However, we are about to rename the output file name from `cygwin1.dll` to `msys-2.0.dll`. Let's preemptively fix up all the import libraries that would link against `msys_2_0.dll` to correctly link against `msys-2.0.dll` instead.
…ent variables to Windows form for native Win32 applications.
…t without ACLs. - Can read /etc/fstab with short mount point format.
The new `winsymlinks` mode `deepcopy` (which is made the default) lets calls to `symlink()` create (deep) copies of the source file/directory. This is necessary because unlike Cygwin, MSYS2 does not try to be its own little ecosystem that lives its life separate from regular Win32 programs: the latter have _no idea_ about Cygwin-emulated symbolic links (i.e. system files whose contents start with `!<symlink>\xff\xfe` and the remainder consists of the NUL-terminated, UTF-16LE-encoded symlink target). To support Cygwin-style symlinks, the new mode `sysfile` is introduced. Co-authored-by: Johannes Schindelin <[email protected]>
With MSys1, it was necessary to set the TERM variable to "msys". To allow for a smooth transition from MSys1 to MSys2, let's simply handle TERM=msys as if the user had not specified TERM at all and wanted us to use our preferred TERM value.
Strace is a Windows program so MSYS2 will convert all arguments and environment vars and that makes debugging msys2 software with strace very tricky.
Commit message for this code was: * strace.cc (create_child): Set CYGWIN=noglob when starting new process so that Cygwin will leave already-parsed the command line alonw." I can see no reason for it and it badly breaks the ability to use strace.exe to investigate calling a Cygwin program from a Windows program, for example: strace mingw32-make.exe .. where mingw32-make.exe finds sh.exe and uses it as the shell. The reason it badly breaks this use-case is because dcrt0.cc depends on globbing to happen to parse commandlines from Windows programs; irrespective of whether they contain any glob patterns or not. See quoted () comment: "This must have been run from a Windows shell, so preserve quotes for globify to play with later."
The biggest problem with strace spitting out `create_child: ...` despite being asked to be real quiet is that its output can very well interfere with scripts' operations. For example, when running any of Git for Windows' shell scripts with `GIT_STRACE_COMMANDS=/path/to/logfile` (which is sadly an often needed debugging technique while trying to address the many MSYS2 issues Git for Windows faces), any time the output of any command is redirected into a variable, it will include that `create_child: ...` line, wreaking havoc with Git's expectations. So let's just really be quiet when we're asked to be quiet. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
rebase-to-v3.5.6
branch
from
f8911d7 to
bd2cc70
Compare
In Cygwin v3.5.6, the `isdevice()` method was dropped, and the commit message of 002aad0 (Cygwin: path_conv: simplify, rearrange, rename combined device checks, 2025-01-21), which is the commit that dropped it, explains: Drop the isdevice() check in favor of a new isondisk() check. On the face of it, the message is clear: we should use `isondisk()` instead of `isdevice()`. As it turns out, MSYS2's code that pretends to create a symbolic link upon `ln -s` but instead makes a deep copy used to call `isdevice()`: if (!src_path.isdevice () && !src_path.is_fs_special ()) // do a deep copy and return // otherwise fall back to creating a sysfile link A deep dive into the issue reveals that in this instance, the condition is actually equivalent to: if (!src_path.isspecial() || (src_path.isfifo() && !src_path.isondisk())) Further study (by trying it out) reveals that replacing this condition with `src_path.isondisk()` fails to produce the expected result. Here is the expected result, which we receive whether we use MSYS2 runtime v3.5.5 or the version with `src_path.isspecial()`: $ mknod foo c 1 3 $ ln -s foo foolnk $ ls -l foo* crw-rw-rw- 1 x None 1, 3 Jan 27 10:43 foo lrwxrwxrwx 1 x None 3 Jan 27 10:43 foolnk -> foo and with `isondisk()`, this happens instead: $ mknod foo c 1 3 $ ln -s foo foolnk $ ls -l foo* crw-rw-rw- 1 x None 1, 3 Jan 27 10:41 foo -r--r--r-- 1 x None 126 Jan 27 10:41 foolnk Further experimentation reveals that FIFOs are handled without bothering with the `isfifo() && !isondisk()` condition, merely testing `!isspecial()` is enough (and recapitulates the behavior of v3.5.5): $ mkfifo fifo $ ln -s fifo fifolnk $ ls -l fifo fifolnk prw-rw-rw- 1 None 0 Jan 27 20:44 fifo lrwxrwxrwx 1 None 4 Jan 27 20:44 fifolnk -> fifo Therefore, let's just go with the sweet-and-simple `!isspecial()`. This commit will live un-autosquashed in the `msys2-3.5.6` branch to allow for all of the above to be documented in the commit history. Helped-by: Jeremy Drake <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Seeing as Git for Windows tries to stay close to the upstream MSYS2 project, it makes sense to integrate their patches verbatim. Signed-off-by: Johannes Schindelin <[email protected]>
Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v2...v4) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Even when the character set is specified as ASCII, we should handle data outside the 7-bit range gracefully by simply copying it, even if it is technically no longer ASCII. This fixes several of Git for Windows' tests, e.g. t7400. Signed-off-by: Johannes Schindelin <[email protected]>
It came in real handy while debugging an issue that strace 'fixed'. Signed-off-by: Johannes Schindelin <[email protected]>
When a non ascii char is at the beginning of a path the current conversion destroys the path. This fix will prevent this with an extra check for non-ascii UTF-8 characters. Helped-by: Johannes Schindelin <[email protected]> Signed-off-by: 마누엘 <[email protected]>
* dcrt0.cc (dll_crt0_1), dtable.cc (handle_to_fn), environ.cc (environ_init, getwinenveq, build_env), external.cc (fillout_pinfo), fhandler_disk_file.cc (__DIR_mounts::eval_ino, fhandler_disk_file::readdir_helper), fhandler_netdrive.cc (fhandler_netdrive::readdir), fhandler_process.cc (format_process_winexename, format_process_maps, format_process_stat, format_process_status), fhandler_procsys.cc (fill_filebuf, fhandler_procsys::readdir), mount.cc (fs_info::update, mount_info::create_root_entry, mount_info::conv_to_posix_path, mount_info::from_fstab_line), nlsfuncs.cc (internal_setlocale), path.cc (path_conv::check, sysmlink_info::check_shortcut, symlink_info::check_sysfile, symlink_info::check_reparse_point, symlink_info::check_nfs_symlink, cygwin_conv_path, cygwin_conv_path_list, cwdstuff::get_error_desc, cwdstuff::get), strfuncs.cc (sys_wcstombs_no_path, sys_wcstombs_alloc_no_path), uinfo.cc (ontherange, fetch_from_path, cygheap_pwdgrp::get_home, cygheap_pwdgrp::get_shell, cygheap_pwdgrp::get_gecos), wchar.h (sys_wcstombs_no_path, sys_wcstombs_alloc_no_path): Convert call sites of the sys_wcstombs*() family to specify explicitly when the parameter refers to a path or file name, to avoid future misconversions. Detailed explanation: The sys_wcstombs() function contains special handling for paths/file names, to work around file name restriction on Windows that are unexpected in the POSIX context of Cygwin. We actually do not want that special handling for WCS strings that do *not* refer to paths or file names. Neither do we want to convert those special file names unless they come from inside Cygwin: if the source of the string value is the Windows API, we *know* it cannot be such a special file name because Windows itself would not be able to handle it in the way Cygwin does. So let's switch the previous sys_wcstombs()/sys_wcstombs_no_path() (and the *_alloc* variant) around to sys_wcstombs_path()/sys_wcstombs(). We do this for several reasons: - whenever a call site wants to convert a WCS representation of a path or file name to an MBS one, it should be made very clear that we *want* the special file name conversion to happen. - it is shorter to read and write. - future calls to sys_wcstombs() will not incur unwanted conversion by accident (it is easy for unsuspecting programmers to assume that the function name "sys_wcstombs()" refers to a regular text conversion that has nothing to do with paths or filenames). By keeping the name sys_wcstombs() (and not switching to sys_wcstombs_path()), the following call sites are implicitly changed to *exclude* the special path/file name conversion: cygheap.h (get_drive): Cannot contain special characters external.cc (cygwin_internal): Refers to user/domain names, not paths fhandler_clipboard.cc (fhandler_dev_clipboard::read): Is not a path or file name but characters from the Windows clipboard fhandler_console.cc: (dev_console::con_to_str): Is not a path or file name but characters from the console fhandler_registry.cc (encode_regname): Is a registry key, not a path or filename fhandler_registry.cc (multi_wcstombs): All call sites pass registry values, not paths or filenames fhandler_registry.cc (fstat): Is a registry value, not a path or filename fhandler_registry.cc (fill_filebuf): Is a registry value, not a path or filename net.cc (get_ipv4fromreg): Is a registry value, not a path or filename net.cc (get_friendlyname): Is a device name, not a path or filename netdb.cc (open_system_file): Is from outside Cygwin smallprint.cc (__small_vsprintf): Is a free text, not a path or filename strfuncs.cc (strlwr): Should preserve the characters from the private page if there are any strfuncs.cc (strupr): Should preserve the characters from the private page if there are any uinfo.cc (cygheap_user::init): Refers to a user name, not a path or filename uinfo.cc (pwdgrp::fetch_account_from_windows): Refers to value from outside Cygwin By keeping the function name sys_wcstombs_alloc() (and not changing it to sys_wcstombs_alloc_path()), the following call sites are implicitly changed to *exclude* the special path/file name conversion: ldap.cc (cyg_ldap::remap_uid): Refers to a user name, not a path or filename ldap.cc (cyg_ldap::remap_gid): Refers to a group name, not a path or filename pinfo.cc (_pinfo::cmdline): Refers to a command line from Windows, outside Cygwin uinfo.cc (cygheap_user::env_logsrv): Is a server name, not a path or filename uinfo.cc (cygheap_user::env_domain): Refers to the user/domain name, not a path or filename uinfo.cc (cygheap_user::env_userprofile): Refers to Windows' idea of a path, outside Cygwin uinfo.cc (cygheap_user::env_systemroot): Refers to Windows' idea of a path, outside Cygwin uinfo.cc (fetch_from_description): Refers to values from outside of Cygwin uinfo.cc (cygheap_pwdgrp::get_gecos): Refers to user/domain name and email address, not path nor filename Signed-off-by: Johannes Schindelin <[email protected]>
Windows native symlinks must match the type of their target (file or directory), otherwise native Windows tools will fail. Creating symlinks in 'nativestrict' mode currently requires the target to exist in order to check its type. However, the target of a symlink can change at any time after the symlink has been created. Thus users of native symlinks must be prepared to deal with type mismatches anyway. Checking the target type at symlink creation time is not a good reason to violate the symlink() API specification. In 'nativestrict' mode, always create native symlinks. Choose the symlink type according to the target if it exists. Otherwise check the target path for a trailing '/' as hint to create a directory symlink. This allows callers to explicitly specify the expected target type, e.g.: $ ln -s test/ link-to-test $ mkdir test Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Assorted fixes for Git for windows
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]>
Internally, Cygwin already uses __utf8_mbtowc(), even if it still claims to use the "ASCII" charset. But the `MB_CUR_MAX` value (which is not actually a constant, but dependent on the current locale) was still 1, which broke the initial `globify()` call while parsing the the command-line in `build_argv()` for non-ASCII arguments. This fixes git-for-windows/git#2189 Signed-off-by: Johannes Schindelin <[email protected]>
Allow native symlinks to non-existing targets in 'nativestrict' mode
This is a forked repository... Signed-off-by: Johannes Schindelin <[email protected]>
This might break things, but it turns out several Windows libraries like to be loaded at 0x180000000. This causes a problem, because `msys-2.0.dll` loads at `0x180040000` and expects `0x180000000-0x180040000` to be available. A problem arises when Antiviruses (or other DLL hooking mechanisms) load a DLL whose preferred load address is `0x180000000` and fits in size before `0x180010000`: 1. `msys-2.0.dll` loads and fills `0x180010000-0x180040000` assuming no shared console structure is going to be needed. 2. Another DLL loads and fills `0x180000000-0x18000xxxx` 3. `msys-2.0.dll` tries to load `0x180000000-0x180010000` but it's not available. It falls back to another address, but down the line something else fails. This bug triggers when using subshells (e.g.: `git clone --recursive`). The MSYS2 runtime should be able to work around the address conflict, but the code is failing in some way or other... Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Mikael Larsson <[email protected]>
This topic branch fixes the problem where a UTF-16 command-line was converted to UTF-8 in an incorrect way (because Cygwin treated it as if it was a file name and applied some magic that is intended to allow for otherwise invalid file names on Windows). Signed-off-by: Johannes Schindelin <[email protected]>
Commit a5bcfe6 removed an optimization that fetches the default group from the current user token, as it is sometimes not accurate such as when groups like the builtin Administrators group is the primary group. However, removing this optimization causes extremely poor performance when connected to some Active Directory environments. Restored this optimization as the default behaviour, and added a `group: db-accurate` option to `nsswitch.conf` that can be used to disable the optimization in cases where accurate group information is required. This fixes git-for-windows/git#4459 Signed-off-by: Richard Glidden <[email protected]>
It was reported in git-for-windows/git#5199 that as of v3.5.4, cloning or fetching via SSH is hanging indefinitely. Bisecting the problem points to 555afcb (Cygwin: select: set pipe writable only if PIPE_BUF bytes left, 2024-08-18). That commit's intention seems to look at the write buffer, and only report the pipe as writable if there are more than one page (4kB) available. However, the number that is looked up is the number of bytes that are already in the buffer, ready to be read, and further analysis shows that in the scenario described in the report, the number of available bytes is substantially below `PIPE_BUF`, but as long as they are not handled, there is apparently a dead-lock. Since the old logic worked, and the new logic causes a dead-lock, let's essentially revert 555afcb (Cygwin: select: set pipe writable only if PIPE_BUF bytes left, 2024-08-18). Note: This is not a straight revert, as the code in question has been modified subsequently, and trying to revert the original commit would cause merge conflicts. Therefore, the diff looks very different from the reverse diff of the commit whose logic is reverted. Signed-off-by: Johannes Schindelin <[email protected]>
One particularly important part of Git for Windows' MSYS2 runtime is that it is used to run Git's tests, and regressions happened there: For example, the first iteration of MSYS2 runtime v3.5.5 caused plenty of hangs. This was realized unfortunately only after deploying the msys2-runtime Pacman package, and some painful vacation-time scrambling was required to revert to v3.5.4.This was realized unfortunately only after deploying the msys2-runtime Pacman package, and some painful vacation-time scrambling was required to revert to v3.5.4. To verify that this does not happen anymore, let's reuse what `setup-git-for-windows-sdk` uses in Git's very own CI: - determine the latest successful `ci-artifacts` workflow run in git-for-windows/git-sdk-64 - download its Git files and build artifacts - download its minimal-sdk - overwrite the MSYS2 runtime in the minimal-sdk - run the test suite and the assorted validations just like the `ci-artifacts` workflow (from which these jobs are copied) This obviously adds a hefty time penalty (around 7 minutes!) to every MSYS2 runtime PR in the git-for-windows org. Happily, these days we don't need many of those, and the balance between things like the v3.5.5 scramble and waiting a little longer for the CI to finish is clearly in favor of the latter. Signed-off-by: Johannes Schindelin <[email protected]>
Workaround certain anti-malware programs Signed-off-by: Johannes Schindelin <[email protected]>
msys2-runtime: restore fast path for current user primary group
Fix SSH hangs
ci: run Git's entire test suite
dscho
force-pushed
the
rebase-to-v3.5.6
branch
from
bd2cc70 to
2a3a6df
Compare
|
Now that the
The fixups have been squashed (and they targeted commits that are in |
|
/open pr The workflow run was started |
This was referenced Jan 28, 2025
msys2-runtime: update to 2a3a6df191a924913cc1610d960a370b0c4fa5c2
git-for-windows/MSYS2-packages#209
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
git range-diff origin/main^{/^Merge.branch.*msys}..origin/main HEAD^{/^Merge.branch.*msys}..