Handle Ctrl+C in Git Bash nicely #1170

dscho · 2017-05-18T13:54:10Z

This PR depends on git-for-windows/msys2-runtime#15.

The idea is that the MSYS2 runtime will no longer kill Git's processes using TerminateProcess(), but by injecting a thread calling ExitProcess(), which in turn allows Git's atexit() handlers to run.

NOTE: this does not mean that we all of a sudden have POSIX semantics. Far from it: there is still no real signal handling (think SIGSTOP and SIGCONT), and the signal handlers are not run.

Git's source code amazingly seems to be prepared for that case, as most (or all?) signal handlers simply enter code paths that are also entered by atexit handlers.

For example, if a long-running git clone is interrupted by Ctrl+C, or by a fatal error, does not matter: in both cases do we want to clean up after us, meaning: the same cleanup functions are called.

This is excellent news, as we now can use the same method as the MSYS2 runtime just learned to kill our child processes when we were "exited" by a signal. And those child processes can do the same in return.

whoisj

In general this looks great. I'll assume you've tested it and it works. 😉

I've left a couple of comments. The assumption in kill_child_processes_on_signal that as long as the exit code is greater than 128, it is OK to exit the process might be invalid though - given that GetExitCodeProcess can return on a still running process and an exit code of 259 on Windows means the process is still running.

Approving the changes, as to not be a blocker - but please review the logic in kill_child_processes_on_signal; also please forgive any stupidity I've displayed as I'm still sipping for first cup of coffee ☕️ .

compat/win32/exit-process.h

+		if (!thread)
+			return terminate_process_tree(process, exit_code);
+		CloseHandle(thread);
+		if (WaitForSingleObject(process, 10000) == WAIT_OBJECT_0)


compat/win32/exit-process.h

+			break;
+	}
+
+	for (i = len - 1; i >= 0; i--) {


compat/mingw.c

+	 * Only continue if the process was terminated by a signal, as
+	 * indicated by the exit status (128 + sig_no).
+	 */
+	if (!GetExitCodeProcess(GetCurrentProcess(), &status) || status < 128)


dscho · 2017-05-18T18:54:49Z

In general this looks great. I'll assume you've tested it and it works.

Yes, I did.

The assumption in kill_child_processes_on_signal that as long as the exit code is greater than 128, it is OK to exit the process might be invalid though - given that GetExitCodeProcess can return on a still running process and an exit code of 259 on Windows means the process is still running.

Well, no, the atexit handler is not started unless the process was exited with an exit status ;-)

But you are correct, I should be a lot more careful here. I changed the code to look for SIGRTMAX (which is not #defined in MINGW, so I fall back to the hard-coded constant 63, which should be "good enough").

whoisj · 2017-05-18T19:54:31Z

But you are correct, I should be a lot more careful here. I changed the code to look for SIGRTMAX (which is not #defined in MINGW, so I fall back to the hard-coded constant 63, which should be "good enough").

I guess my concern here is that you're asking "what is my exit code" which in theory, because you (the current process) is asking, the value is 259. Which makes the conditional kind of pointless.

Does the call to ExitProcess set the exit code before kill_child_processes_on_signal gets called?

compat/mingw.c

+	 * Only continue if the process was terminated by a signal, as
+	 * indicated by the exit status (128 + sig_no).
+	 */
+	if (!GetExitCodeProcess(GetCurrentProcess(), &status) ||


compat/mingw.c

 		}

-		errno = err_win_to_posix(GetLastError());
+		ret = exit_process(h, 3);


jeffhostetler · 2017-05-18T20:11:17Z

Many of my comments in https://github.com/git-for-windows/msys2-runtime/pull/15/files also apply to this PR. I didn't bother repeating them here.

dscho · 2017-05-18T20:58:32Z

Does the call to ExitProcess set the exit code before kill_child_processes_on_signal gets called?

Yep.

dscho · 2017-05-18T21:11:09Z

This revision should be good.

compat/win32/exit-process.h

+		if (!initialized) {
+			HINSTANCE kernel32 = GetModuleHandle("kernel32");
+			if (!kernel32)
+				die("BUG: cannot find kernel32");


whoisj · 2017-05-19T04:04:20Z

@dscho please seem my comment on https://github.com/git-for-windows/msys2-runtime/pull/15/files#r117399303 about making this work when msys is 64-bit and the target is 32-bit.

dscho · 2017-05-19T09:16:36Z

I just had another fresh look over the overall diff, and I realized that the exit code 128 does not signify exit-by-signal (signal numbers start at 1, for SIGHUP). Instead, it is the exit code Git uses for fatal errors (die()). So the test status < 128 was incorrect, and I fixed it by replacing it with status <= 128.

dscho · 2017-05-19T09:55:28Z

I also realized a problem with the IsWoW64Process() test: what we really want is to ensure that the current process' architecture matches the one of the process to be killed. But what we tested was that that the process to be killed matches the OS' architecture. Therefore, we would have tried to kill a 64-bit process on a 64-bit OS when running as 32-bit git.exe.

I adjusted the test to verify that IsWow64Process() returns the same value for the current process and the one to be killed. The code is less elegant than I want it to be, but I could not find a way to make it better...

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]>

Git for Windows' MSYS2 runtime was just adjusted to kill processes gently, by injecting a thread that calls ExitProcess(). In case of signals (such as when handling Ctrl+C in a MinTTY window), the exit code is 128 + sign_no, as expected by Git's source code. However, as there is no POSIX signal handling on Windows, no signal handlers are called. Instead, functions registered via atexit() are called. We work around that by testing the exit code explicitly. This fixes the Git for Windows side of the bug where interrupting `git clone https://...` would send the spawned-off `git remote-https` process into the background instead of interrupting it, i.e. the clone would continue and its progress would be reported mercilessly to the console window without the user being able to do anything about it (short of firing up the task manager and killing the appropriate task manually). Signed-off-by: Johannes Schindelin <[email protected]>

When interrupting Git processes in Git Bash by pressing Ctrl+C, [Git now removes `.lock` files as designed](git-for-windows/msys2-runtime#15) ([accompanying Git PR](git-for-windows/git#1170); this should also fix [issue #338](git-for-windows/git#338)). Signed-off-by: Johannes Schindelin <[email protected]>

Handle Ctrl+C in Git Bash nicely

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

commit 2996b56fa7470c29e418e4e7249629ea74cdfdca Author: Johannes Schindelin <[email protected]> Date: Fri Oct 11 16:55:26 2024 +0200 amend! Add experimental 'git survey' builtin (#5174) Add experimental 'git survey' builtin (#5174) This introduces `git survey` to Git for Windows ahead of upstream for the express purpose of getting the path-based analysis in the hands of more folks. The inspiration of this builtin is [`git-sizer`](https://github.com/github/git-sizer), but since that command relies on `git cat-file --batch` to get the contents of objects, it has limits to how much information it can provide. This is mostly a rewrite of the `git survey` builtin that was introduced into the `microsoft/git` fork in microsoft/git#667. That version had a lot more bells and whistles, including an analysis much closer to what `git-sizer` provides. The biggest difference in this version is that this one is focused on using the path-walk API in order to visit batches of objects based on a common path. This allows identifying, for instance, the path that is contributing the most to the on-disk size across all versions at that path. For example, here are the top ten paths contributing to my local Git repository (which includes `microsoft/git` and `gitster/git`): ``` TOP FILES BY DISK SIZE ============================================================================ Path | Count | Disk Size | Inflated Size -----------------------------------------+-------+-----------+-------------- whats-cooking.txt | 1373 | 11637459 | 37226854 t/helper/test-gvfs-protocol | 2 | 6847105 | 17233072 git-rebase--helper | 1 | 6027849 | 15269664 compat/mingw.c | 6111 | 5194453 | 463466970 t/helper/test-parse-options | 1 | 3420385 | 8807968 t/helper/test-pkt-line | 1 | 3408661 | 8778960 t/helper/test-dump-untracked-cache | 1 | 3408645 | 8780816 t/helper/test-dump-fsmonitor | 1 | 3406639 | 8776656 po/vi.po | 104 | 1376337 | 51441603 po/de.po | 210 | 1360112 | 71198603 ``` This kind of analysis has been helpful in identifying the reasons for growth in a few internal monorepos. Those findings motivated the changes in #5157 and #5171. With this early version in Git for Windows, we can expand the reach of the experimental tool in advance of it being contributed to the upstream project. Unfortunately, this will mean that in the next `microsoft/git` rebase, Jeff Hostetler's version will need to be pulled out since there are enough conflicts. These conflicts include how tables are stored and generated, as the version in this PR is slightly more general to allow for different kinds of data. Signed-off-by: Johannes Schindelin <[email protected]> commit 5f1db046948aa39d2a28ddc9fba5a8975df40fa3 Author: Johannes Schindelin <[email protected]> Date: Fri Oct 11 16:54:53 2024 +0200 amend! path-walk: improve path-walk speed with many tags (#5205) path-walk: improve path-walk speed with many tags (#5205) In the presence of many tags, the use of oid_array_lookup() can become extremely slow. We should rely upon the SEEN bit instead. This affects the tag-peeling walk as well as the switch statement for adding the peeled object to the correct oid_array. ---- Derrick Stolee found this while testing the 2.47.0.vfs.0.0 pre-release against a repo with many annotated tags. This is a backport of https://github.com/microsoft/git/pull/695. Signed-off-by: Johannes Schindelin <[email protected]> commit f380030a00c15fa00d66799f875cf2c986e1fc97 Merge: 61ec9331b6 c33368b771 Author: Johannes Schindelin <[email protected]> Date: Fri Oct 11 13:58:53 2024 +0200 path-walk: improve path-walk speed with many tags (#5205) In the presence of many tags, the use of oid_array_lookup() can become extremely slow. We should rely upon the SEEN bit instead. This affects the tag-peeling walk as well as the switch statement for adding the peeled object to the correct oid_array. ---- @derrickstolee found this while testing the 2.47.0.vfs.0.0 pre-release against a repo with many annotated tags. This is a backport of https://github.com/microsoft/git/pull/695. commit 61ec9331b61ab857a259d6e1c4c4f86775b34f26 Merge: 12031c299c 3ead00a02c Author: Johannes Schindelin <[email protected]> Date: Thu Jun 7 08:45:01 2018 +0200 Merge 'readme' into HEAD Add a README.md for GitHub goodness. Signed-off-by: Johannes Schindelin <[email protected]> commit c33368b7717c90296ad2ffac3b8ffb364e6173ef Author: Derrick Stolee <[email protected]> Date: Wed Oct 9 09:57:32 2024 -0400 path-walk: improve path-walk speed with many tags In the presence of many tags, the use of oid_array_lookup() can become extremely slow. We should rely upon the SEEN bit instead. This affects the tag-peeling walk as well as the switch statement for adding the peeled object to the correct oid_array. Signed-off-by: Derrick Stolee <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 12031c299c10eeb8af636303901db371b931b272 Merge: 3c2f5aa314 740b27f844 Author: Johannes Schindelin <[email protected]> Date: Wed Oct 7 16:13:40 2020 +0200 Merge pull request #2837 from dscho/monitor-component-updates Start monitoring updates of Git for Windows' component in the open commit 3c2f5aa3148b8487f15ab828482ddc4e222c5262 Merge: fe2b01e513 8c90275e38 Author: Johannes Schindelin <[email protected]> Date: Tue Jan 24 11:46:21 2023 +0100 Merge branch 'deprecate-core.useBuiltinFSMonitor' 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]> commit fe2b01e51341088486df2b3747c0a40b365af1a5 Merge: c36a4deb88 aa062e96ec Author: Johannes Schindelin <[email protected]> Date: Fri Jun 8 18:34:51 2018 +0200 Merge branch 'phase-out-reset-stdin' 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]> commit c36a4deb885361c37441564b1c62731809aa3917 Merge: 2fdfc3089a 2711b9ca0a Author: Johannes Schindelin <[email protected]> Date: Sat Jan 15 11:37:56 2022 +0100 Merge branch 'un-revert-editor-save-and-reset' 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]> commit 2fdfc3089a6e7dd44a8c373f68bfaf6950c4da12 Merge: 42778ded1e a5cc82fd83 Author: Victoria Dye <[email protected]> Date: Thu Oct 28 15:16:10 2021 -0400 Merge pull request #3492 from dscho/ns/batched-fsync Switch to batched fsync by default commit 42778ded1e9b9bac269a37c3e4c163dbb200a853 Merge: 0d956e0879 7e12ac9200 Author: Johannes Schindelin <[email protected]> Date: Thu Oct 11 23:29:20 2018 +0200 Merge pull request #1170 from dscho/mingw-kill-process Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]> commit 0d956e0879144c6c6d736dde7ac80c3bf30c73a6 Merge: 7773e3c9fa 0a57a784e6 Author: Johannes Schindelin <[email protected]> Date: Mon Aug 7 22:24:29 2023 +0200 Merge branch 'wsl-file-mode-bits' 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]> commit 7773e3c9fac969b26c6c0238053fb9f7e511d147 Merge: fd8673cf9c c576da7398 Author: Johannes Schindelin <[email protected]> Date: Thu Feb 7 14:35:33 2019 +0100 Merge branch 'busybox-w32' Signed-off-by: Johannes Schindelin <[email protected]> commit fd8673cf9cf25119fbc242960b08fa9c4c0412fb Merge: 2a3d2866f2 3feb8f7dfb Author: Johannes Schindelin <[email protected]> Date: Wed Oct 31 15:08:16 2018 +0100 Merge pull request #1897 from piscisaureus/symlink-attr Specify symlink type in .gitattributes commit 2a3d2866f2186843b09b922c25f6ca9c750e0770 Merge: 4725764578 f93344df80 Author: Johannes Schindelin <[email protected]> Date: Mon Aug 7 16:12:10 2023 +0200 mingw: try resetting the read-only bit if rename fails (#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]> commit 4725764578421fc40b2de1b230f31e7af6d62055 Merge: a4ba13da06 426566b1e4 Author: Johannes Schindelin <[email protected]> Date: Fri Oct 12 23:04:03 2018 +0200 Merge 'docker-volumes-are-no-symlinks' This was pull request #1645 from ZCube/master Support windows container. Signed-off-by: Johannes Schindelin <[email protected]> commit a4ba13da0615d74ad7c8b4ed9488bee4edd91e2b Merge: f860813f4e bd2c03e214 Author: Johannes Schindelin <[email protected]> Date: Thu Nov 15 12:23:43 2018 +0100 Merge branch 'kblees/kb/symlinks' Signed-off-by: Johannes Schindelin <[email protected]> commit f860813f4e58b4050eec6c2cd4a896aad7ea6cc5 Merge: 343c75d471 b9a9681993 Author: Johannes Schindelin <[email protected]> Date: Thu Nov 15 12:23:43 2018 +0100 Merge branch 'msys2' commit 343c75d4716087b9a4a787a400c9391ba4248460 Merge: 86a198c2e2 0987f685d1 Author: Johannes Schindelin <[email protected]> Date: Fri Apr 22 23:46:50 2022 +0200 Merge pull request #3817 from mathstuf/name-too-long-advice clean: suggest using `core.longPaths` if paths are too long to remove commit 86a198c2e27492928a052f924509c5ec5d4cc03c Merge: c7917ce9d3 29f7afc8f8 Author: Jeff Hostetler <[email protected]> Date: Wed Sep 29 17:58:38 2021 -0400 Merge branch 'fix-v4-fsmonitor-long-paths' into try-v4-fsmonitor commit c7917ce9d3aaa7a78b42a2eb59519472b7582971 Merge: fa336b3e18 b8923c8fba Author: Johannes Schindelin <[email protected]> Date: Thu Nov 15 12:23:43 2018 +0100 Merge branch 'long-paths' commit fa336b3e18bd1ae110429fbfffa61e42cc6cd665 Merge: b885fdedff f210ba75b1 Author: Johannes Schindelin <[email protected]> Date: Thu Oct 11 13:38:58 2018 +0200 Merge branch 'gitk-and-git-gui-patches' 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]> commit 3ead00a02cbbe54627fd9a2f0a64d9cc19167aa6 Author: Johannes Schindelin <[email protected]> Date: Fri Aug 23 14:14:42 2019 +0200 SECURITY.md: document Git for Windows' policies This is the recommended way on GitHub to describe policies revolving around security issues and about supported versions. Signed-off-by: Johannes Schindelin <[email protected]> commit 740b27f84487f3459c3be078bba05587b6038a09 Author: Johannes Schindelin <[email protected]> Date: Tue Feb 6 18:45:35 2024 +0100 dependabot: help keeping GitHub Actions versions up to date 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]> commit 3092e2ace9b944fe13be59dbe5839ab5bc4e9a4e Author: Alejandro Barreto <[email protected]> Date: Fri Mar 9 14:17:54 2018 -0600 Document how $HOME is set on Windows Git documentation refers to $HOME and $XDG_CONFIG_HOME often, but does not specify how or where these values come from on Windows where neither is set by default. The new documentation reflects the behavior of setup_windows_environment() in compat/mingw.c. Signed-off-by: Alejandro Barreto <[email protected]> commit 43ce7da7f3866891bfddef68d1e4353838711f9d Author: Johannes Schindelin <[email protected]> Date: Tue Feb 20 15:44:57 2018 +0100 .github: Add configuration for the Sentiment Bot The sentiment bot will help detect when things get too heated. Hopefully. Signed-off-by: Johannes Schindelin <[email protected]> commit b1fc6f3c7b58dab4a2e0e35a9b980f9feaa11efe Author: Philip Oakley <[email protected]> Date: Fri Dec 22 17:15:50 2017 +0000 Modify the GitHub Pull Request template (to reflect Git for Windows) 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]> commit f95739fa44d273f84a4801aab986f83d5cac3406 Author: Brendan Forster <[email protected]> Date: Thu Feb 18 21:29:50 2016 +1100 Add an issue template 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]> commit 862899ec93dc1cb1d91e0eeb31d0c3c6b2c57211 Author: Johannes Schindelin <[email protected]> Date: Fri Jan 10 16:16:03 2014 -0600 README.md: Add a Windows-specific preamble Includes touch-ups by 마누엘, Philip Oakley and 孙卓识. Signed-off-by: Johannes Schindelin <[email protected]> commit 58997bb46572ba290809301db1b547223004af42 Author: Derrick Stolee <[email protected]> Date: Thu Mar 1 12:10:14 2018 -0500 CONTRIBUTING.md: add guide for first-time contributors Getting started contributing to Git can be difficult on a Windows machine. CONTRIBUTING.md contains a guide to getting started, including detailed steps for setting up build tools, running tests, and submitting patches to upstream. [includes an example by Pratik Karki how to submit v2, v3, v4, etc.] Signed-off-by: Derrick Stolee <[email protected]> commit 12e0f90bea754eebe6ddf4c5b2af79572a891a63 Author: Johannes Schindelin <[email protected]> Date: Fri Oct 11 13:22:24 2019 +0200 Modify the Code of Conduct for Git for Windows The Git project followed Git for Windows' lead and added their Code of Conduct, based on the Contributor Covenant v1.4, later updated to v2.0. We adapt it slightly to Git for Windows. Signed-off-by: Johannes Schindelin <[email protected]> commit 898aba7180f0de1d7a26a12ce810788614c4f7b1 Author: Johannes Schindelin <[email protected]> Date: Mon Feb 13 13:31:35 2023 +0100 Describe Git for Windows' architecture [no ci] The Git for Windows project has grown quite complex over the years, certainly much more complex than during the first years where the `msysgit.git` repository was abusing Git for package management purposes and the `git/git` fork was called `4msysgit.git`. Let's describe the status quo in a thorough way. Signed-off-by: Johannes Schindelin <[email protected]> commit 8c90275e38a704e321af7f7cd1c42911526f6fff Author: Victoria Dye <[email protected]> Date: Mon Apr 4 15:38:58 2022 -0700 fsmonitor: reintroduce core.useBuiltinFSMonitor Reintroduce the 'core.useBuiltinFSMonitor' config setting (originally added in 0a756b2a25 (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]> commit aa062e96ec4348844793382b3eb1cb14c777372e Author: Johannes Schindelin <[email protected]> Date: Tue Dec 10 21:41:57 2019 +0100 reset: reinstate support for the deprecated --stdin option 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]> commit 2711b9ca0a7639de281c8f289c52083823728e03 Author: Johannes Schindelin <[email protected]> Date: Thu Nov 25 11:26:41 2021 +0100 Partially un-revert "editor: save and reset terminal after calling EDITOR" In e3f7e01b50be (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]> commit 281b4c972ab365c75653b88c4628698f8bc27858 Author: Johannes Schindelin <[email protected]> Date: Tue Sep 29 13:50:59 2020 +0200 Add a GitHub workflow to monitor component updates 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]> commit a5cc82fd8332925e77b1acf9714959e47ff67932 Author: Neeraj K. Singh <[email protected]> Date: Wed Oct 27 14:22:42 2021 -0700 mingw: do not call xutftowcs_path in mingw_mktemp The `xutftowcs_path` function canonicalizes absolute paths using GetFullPathNameW. This canonicalization may change the length of the string (e.g. getting rid of \.\), which breaks callers that pass the template string in a strbuf and expect the length of the string to remain the same. In my particular case, the tmp-objdir code is passing a strbuf to mkdtemp and is breaking since the strbuf.len is no longer synchronized with strlen(strbuf.buf). Signed-off-by: Neeraj K. Singh <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 7e12ac9200f6795d579a77b01d866a9123a81b74 Author: Johannes Schindelin <[email protected]> Date: Mon Apr 23 00:24:29 2018 +0200 mingw: really handle SIGINT 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]> commit 1c88e62100f1cdf513bb74e9bbe7bbf018f1d6c6 Author: Johannes Schindelin <[email protected]> Date: Wed May 17 17:05:09 2017 +0200 mingw: kill child processes in a gentler way 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]> commit 0a57a784e6a1b684ed4f5f6bf2b4e96e62261e3f Author: xungeng li <[email protected]> Date: Wed Jun 7 20:26:33 2023 +0800 mingw: optionally enable wsl compability file mode bits 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]> commit c576da7398572a272d490aea4d42f783130529dc Author: Johannes Schindelin <[email protected]> Date: Thu Jul 20 00:23:26 2017 +0200 mingw: add a Makefile target to copy test artifacts 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]> commit 68a9e1049d8af655ffdc19513654f4cb79116825 Author: Johannes Schindelin <[email protected]> Date: Fri Jul 7 10:15:36 2017 +0200 t9200: skip tests when $PWD contains a colon 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]> commit 895c312461bb353a31cc6b1bb8460cb65a75fe86 Author: Johannes Schindelin <[email protected]> Date: Wed Jul 5 15:14:50 2017 +0200 t5813: allow for $PWD to be a Windows path 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]> commit 9cc63e93ae3d0bd959c09c2ef321777d71d60497 Author: Johannes Schindelin <[email protected]> Date: Fri Jul 21 13:24:55 2017 +0200 t5605: special-case hardlink test for BusyBox-w32 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]> commit 40c1fdd50bc71a91773792a86a16034e2f880bd2 Author: Johannes Schindelin <[email protected]> Date: Fri Jul 21 12:48:33 2017 +0200 t5532: workaround for BusyBox on Windows 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]> commit cc77bda048f544e7469f7b39ea584431faef7475 Author: Johannes Schindelin <[email protected]> Date: Sat Aug 5 21:36:01 2017 +0200 t5003: use binary file from t/lib-diff/ At some stage, t5003-archive-zip wants to add a file that is not ASCII. To that end, it uses /bin/sh. But that file may actually not exist (it is too easy to forget that not all the world is Unix/Linux...)! Besides, we already have perfectly fine binary files intended for use solely by the tests. So let's use one of them instead. Signed-off-by: Johannes Schindelin <[email protected]> commit e31674004b7bbc4205ab017bdfa0912d8500612b Author: Johannes Schindelin <[email protected]> Date: Wed Jul 19 17:07:56 2017 +0200 test-lib: add BUSYBOX prerequisite When running with BusyBox, we will want to avoid calling executables on the PATH that are implemented in BusyBox itself. Signed-off-by: Johannes Schindelin <[email protected]> commit ee93b74edbb7baafc3d937a29e70b69c6ea54056 Author: Johannes Schindelin <[email protected]> Date: Fri Jun 30 22:32:33 2017 +0200 tests (mingw): remove Bash-specific pwd option The -W option is only understood by MSYS2 Bash's pwd command. We already make sure to override `pwd` by `builtin pwd -W` for MINGW, so let's not double the effort here. This will also help when switching the shell to another one (such as BusyBox' ash) whose pwd does *not* understand the -W option. Signed-off-by: Johannes Schindelin <[email protected]> commit c242e5bae9f7ba61d0c5a40a94a85240f925be23 Author: Johannes Schindelin <[email protected]> Date: Fri Jun 30 00:35:40 2017 +0200 mingw: only use Bash-ism `builtin pwd -W` when available Traditionally, Git for Windows' SDK uses Bash as its default shell. However, other Unix shells are available, too. Most notably, the Win32 port of BusyBox comes with `ash` whose `pwd` command already prints Windows paths as Git for Windows wants them, while there is not even a `builtin` command. Therefore, let's be careful not to override `pwd` unless we know that the `builtin` command is available. Signed-off-by: Johannes Schindelin <[email protected]> commit 416f9924f5b2d9dc491b1e18d3df868136c6bafd Author: Johannes Schindelin <[email protected]> Date: Mon Nov 19 20:34:13 2018 +0100 tests: use the correct path separator with BusyBox BusyBox-w32 is a true Win32 application, i.e. it does not come with a POSIX emulation layer. That also means that it does *not* use the Unix convention of separating the entries in the PATH variable using colons, but semicolons. However, there are also BusyBox ports to Windows which use a POSIX emulation layer such as Cygwin's or MSYS2's runtime, i.e. using colons as PATH separators. As a tell-tale, let's use the presence of semicolons in the PATH variable: on Unix, it is highly unlikely that it contains semicolons, and on Windows (without POSIX emulation), it is virtually guaranteed, as everybody should have both $SYSTEMROOT and $SYSTEMROOT/system32 in their PATH. Signed-off-by: Johannes Schindelin <[email protected]> commit ece253d9dab1d398b9a897caf0324dcd64c0a662 Author: Johannes Schindelin <[email protected]> Date: Tue Jul 18 01:15:40 2017 +0200 tests: only override sort & find if there are usable ones in /usr/bin/ The idea is to allow running the test suite on MinGit with BusyBox installed in /mingw64/bin/sh.exe. In that case, we will want to exclude sort & find (and other Unix utilities) from being bundled. Signed-off-by: Johannes Schindelin <[email protected]> commit 87fcc0611ca22bbad574c939ab32f955fb0e6507 Author: Johannes Schindelin <[email protected]> Date: Sat Aug 5 20:28:37 2017 +0200 tests: move test PNGs into t/lib-diff/ We already have a directory where we store files intended for use by multiple test scripts. The same directory is a better home for the test-binary-*.png files than t/. Signed-off-by: Johannes Schindelin <[email protected]> commit 9679df2f5509f8b988b79812a1712ecd2c531916 Author: Johannes Schindelin <[email protected]> Date: Thu Oct 11 23:55:44 2018 +0200 gitattributes: mark .png files as binary Signed-off-by: Johannes Schindelin <[email protected]> commit 271dace1e6bc34defdda72628732733cbd82d888 Author: Johannes Schindelin <[email protected]> Date: Thu Jul 20 22:25:21 2017 +0200 tests(mingw): if `iconv` is unavailable, use `test-helper --iconv` Signed-off-by: Johannes Schindelin <[email protected]> commit 61271ae6f4a22d6b4bdee5f2cc5359c4dbc37e6e Author: Johannes Schindelin <[email protected]> Date: Thu Jul 20 22:18:56 2017 +0200 test-tool: learn to act as a drop-in replacement for `iconv` It is convenient to assume that everybody who wants to build & test Git has access to a working `iconv` executable (after all, we already pretty much require libiconv). However, that limits esoteric test scenarios such as Git for Windows', where an end user installation has to ship with `iconv` for the sole purpose of being testable. That payload serves no other purpose. So let's just have a test helper (to be able to test Git, the test helpers have to be available, after all) to act as `iconv` replacement. Signed-off-by: Johannes Schindelin <[email protected]> commit fb11e63d6d3430e62a8fc2372736034a8af929ed Author: Johannes Schindelin <[email protected]> Date: Sat Aug 5 22:23:36 2017 +0200 test-lib: avoid unnecessary Perl invocation It is a bit strange, and even undesirable, to require Perl just to run the test suite even when NO_PERL was set. This patch does not fix this problem by any stretch of imagination. However, it fixes *the* Perl invocation that *every single* test script has to run. While at it, it makes the source code also more grep'able, as the code that unsets some, but not all, GIT_* environment variables just became a *lot* more explicit. And all that while still reducing the total number of lines. Signed-off-by: Johannes Schindelin <[email protected]> commit 69165a9a4807e855b634f96e573ba8f120fc6ee4 Author: Johannes Schindelin <[email protected]> Date: Thu Jul 20 20:41:29 2017 +0200 mingw: when path_lookup() failed, try BusyBox BusyBox comes with a ton of applets ("applet" being the identical concept to Git's "builtins"). And similar to Git's builtins, the applets can be called via `busybox <command>`, or the BusyBox executable can be copied/hard-linked to the command name. The similarities do not end here. Just as with Git's builtins, it is problematic that BusyBox' hard-linked applets cannot easily be put into a .zip file: .zip archives have no concept of hard-links and therefore would store identical copies (and also extract identical copies, "inflating" the archive unnecessarily). To counteract that issue, MinGit already ships without hard-linked copies of the builtins, and the plan is to do the same with BusyBox' applets: simply ship busybox.exe as single executable, without hard-linked applets. To accommodate that, Git is being taught by this commit a very special trick, exploiting the fact that it is possible to call an executable with a command-line whose argv[0] is different from the executable's name: when `sh` is to be spawned, and no `sh` is found in the PATH, but busybox.exe is, use that executable (with unchanged argv). Likewise, if any executable to be spawned is not on the PATH, but busybox.exe is found, parse the output of `busybox.exe --help` to find out what applets are included, and if the command matches an included applet name, use busybox.exe to execute it. Signed-off-by: Johannes Schindelin <[email protected]> commit 3feb8f7dfb06fb497fcc8472497b05a04c1fe209 Author: Bert Belder <[email protected]> Date: Fri Oct 26 23:42:09 2018 +0200 Win32: symlink: add test for `symlink` attribute To verify that the symlink is resolved correctly, we use the fact that `git.exe` is a native Win32 program, and that `git.exe config -f <path>` therefore uses the native symlink resolution. Signed-off-by: Bert Belder <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit f93344df80b4572059b2a73de44512ee4bfcba84 Author: David Lomas <[email protected]> Date: Fri Jul 28 15:20:43 2023 +0100 mingw: work around rename() failing on a read-only file At least on _some_ APFS network shares, Git fails to rename the object files because they are marked as read-only, because that has the effect of setting the uchg flag on APFS, which then means the file can't be renamed or deleted. To work around that, when a rename failed, and the read-only flag is set, try to turn it off and on again. This fixes https://github.com/git-for-windows/git/issues/4482 Signed-off-by: David Lomas <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 426566b1e42954be10d43b8367342cffe03f718e Author: Johannes Schindelin <[email protected]> Date: Mon Apr 23 23:20:00 2018 +0200 mingw: Windows Docker volumes are *not* symbolic links ... even if they may look like them. As looking up the target of the "symbolic link" (just to see whether it starts with `/ContainerMappedDirectories/`) is pretty expensive, we do it when we can be *really* sure that there is a possibility that this might be the case. Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: JiSeop Moon <[email protected]> commit db57f75bc17c4fad6ae9e345e321ac8ffff6ef3e Author: Johannes Schindelin <[email protected]> Date: Thu Jul 20 22:45:01 2017 +0200 mingw: explicitly specify with which cmd to prefix the cmdline The main idea of this patch is that even if we have to look up the absolute path of the script, if only the basename was specified as argv[0], then we should use that basename on the command line, too, not the absolute path. This patch will also help with the upcoming patch where we automatically substitute "sh ..." by "busybox sh ..." if "sh" is not in the PATH but "busybox" is: we will do that by substituting the actual executable, but still keep prepending "sh" to the command line. Signed-off-by: Johannes Schindelin <[email protected]> commit 2251b4fce26326ae9c0f163a7f32b00d226b801e Author: Bert Belder <[email protected]> Date: Fri Oct 26 11:51:51 2018 +0200 mingw: allow to specify the symlink type in .gitattributes On Windows, symbolic links have a type: a "file symlink" must point at a file, and a "directory symlink" must point at a directory. If the type of symlink does not match its target, it doesn't work. Git does not record the type of symlink in the index or in a tree. On checkout it'll guess the type, which only works if the target exists at the time the symlink is created. This may often not be the case, for example when the link points at a directory inside a submodule. By specifying `symlink=file` or `symlink=dir` the user can specify what type of symlink Git should create, so Git doesn't have to rely on unreliable heuristics. Signed-off-by: Bert Belder <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 3dbd00ff85659be1f0cc300fda9b1caae4b39e1f Author: JiSeop Moon <[email protected]> Date: Mon Apr 23 22:35:26 2018 +0200 mingw: move the file_attr_to_st_mode() function definition In preparation for making this function a bit more complicated (to allow for special-casing the `ContainerMappedDirectories` in Windows containers, which look like a symbolic link, but are not), let's move it out of the header. Signed-off-by: JiSeop Moon <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 2a564d1c88b7bcf970b41afe94997a3ecb11b225 Author: Johannes Schindelin <[email protected]> Date: Mon Feb 11 14:19:18 2019 +0100 Introduce helper to create symlinks that knows about index_state On Windows, symbolic links actually have a type depending on the target: it can be a file or a directory. In certain circumstances, this poses problems, e.g. when a symbolic link is supposed to point into a submodule that is not checked out, so there is no way for Git to auto-detect the type. To help with that, we will add support over the course of the next commits to specify that symlink type via the Git attributes. This requires an index_state, though, something that Git for Windows' `symlink()` replacement cannot know about because the function signature is defined by the POSIX standard and not ours to change. So let's introduce a helper function to create symbolic links that *does* know about the index_state. Signed-off-by: Johannes Schindelin <[email protected]> commit 7c48a30c9c1a82f25137192c1a3ad23ce2df45f4 Author: JiSeop Moon <[email protected]> Date: Mon Apr 23 22:31:42 2018 +0200 mingw: when running in a Windows container, try to rename() harder It is a known issue that a rename() can fail with an "Access denied" error at times, when copying followed by deleting the original file works. Let's just fall back to that behavior. Signed-off-by: JiSeop Moon <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 954733566ebe8baf18f0f64fc56b27094e8d8273 Author: Bert Belder <[email protected]> Date: Fri Oct 26 11:13:45 2018 +0200 Win32: symlink: move phantom symlink creation to a separate function Signed-off-by: Bert Belder <[email protected]> commit bd2c03e21439ab4399fabd3dd0735bed03393e0a Author: Johannes Schindelin <[email protected]> Date: Thu Jun 4 23:16:07 2020 +0200 mingw: special-case index entries for symlinks with buggy size In https://github.com/git-for-windows/git/pull/2637, we fixed a bug where symbolic links' target path sizes were recorded incorrectly in the index. The downside of this fix was that every user with tracked symbolic links in their checkouts would see them as modified in `git status`, but not in `git diff`, and only a `git add <path>` (or `git add -u`) would "fix" this. Let's do better than that: we can detect that situation and simply pretend that a symbolic link with a known bad size (or a size that just happens to be that bad size, a _very_ unlikely scenario because it would overflow our buffers due to the trailing NUL byte) means that it needs to be re-checked as if we had just checked it out. Signed-off-by: Johannes Schindelin <[email protected]> commit 783d2ff71119dc92a4c3c079f3cbe8cca6eb16cf Author: JiSeop Moon <[email protected]> Date: Mon Apr 23 22:30:18 2018 +0900 mingw: introduce code to detect whether we're inside a Windows container This will come in handy in the next commit. Signed-off-by: JiSeop Moon <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 048c98b04bb5a1bb785d40ba702f9847fa9d0740 Author: Johannes Schindelin <[email protected]> Date: Mon Mar 2 21:54:29 2020 +0100 mingw: emulate stat() a little more faithfully When creating directories via `safe_create_leading_directories()`, we might encounter an already-existing directory which is not readable by the current user. To handle that situation, Git's code calls `stat()` to determine whether we're looking at a directory. In such a case, `CreateFile()` will fail, though, no matter what, and consequently `mingw_stat()` will fail, too. But POSIX semantics seem to still allow `stat()` to go forward. So let's call `mingw_lstat()` for the rescue if we fail to get a file handle due to denied permission in `mingw_stat()`, and fill the stat info that way. We need to be careful to not allow this to go forward in case that we're looking at a symbolic link: to resolve the link, we would still have to create a file handle, and we just found out that we cannot. Therefore, `stat()` still needs to fail with `EACCES` in that case. This fixes https://github.com/git-for-windows/git/issues/2531. Signed-off-by: Johannes Schindelin <[email protected]> commit cb8f3ed7022fa1ddf2097da3db9f69ddfa968540 Author: Johannes Schindelin <[email protected]> Date: Tue May 30 21:50:57 2017 +0200 mingw: try to create symlinks without elevated permissions With Windows 10 Build 14972 in Developer Mode, a new flag is supported by CreateSymbolicLink() to create symbolic links even when running outside of an elevated session (which was previously required). This new flag is called SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE and has the numeric value 0x02. Previous Windows 10 versions will not understand that flag and return an ERROR_INVALID_PARAMETER, therefore we have to be careful to try passing that flag only when the build number indicates that it is supported. For more information about the new flag, see this blog post: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ This patch is loosely based on the patch submitted by Samuel D. Leslie as https://github.com/git-for-windows/git/pull/1184. Signed-off-by: Johannes Schindelin <[email protected]> commit cdebdc1d15e108a7b2d2671e38e60499954ec3c3 Author: Karsten Blees <[email protected]> Date: Sun May 24 01:48:35 2015 +0200 Win32: symlink: add support for symlinks to directories Symlinks on Windows have a flag that indicates whether the target is a file or a directory. Symlinks of wrong type simply don't work. This even affects core Win32 APIs (e.g. DeleteFile() refuses to delete directory symlinks). However, CreateFile() with FILE_FLAG_BACKUP_SEMANTICS doesn't seem to care. Check the target type by first creating a tentative file symlink, opening it, and checking the type of the resulting handle. If it is a directory, recreate the symlink with the directory flag set. It is possible to create symlinks before the target exists (or in case of symlinks to symlinks: before the target type is known). If this happens, create a tentative file symlink and postpone the directory decision: keep a list of phantom symlinks to be processed whenever a new directory is created in mingw_mkdir(). Limitations: This algorithm may fail if a link target changes from file to directory or vice versa, or if the target directory is created in another process. Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 7eb9bc36a16cbbfb90cf07d8e274de36198ed42b Author: Karsten Blees <[email protected]> Date: Sun May 24 01:32:03 2015 +0200 Win32: implement basic symlink() functionality (file symlinks only) Implement symlink() that always creates file symlinks. Fails with ENOSYS if symlinks are disabled or unsupported. Note: CreateSymbolicLinkW() was introduced with symlink support in Windows Vista. For compatibility with Windows XP, we need to load it dynamically and fail gracefully if it isnt's available. Signed-off-by: Karsten Blees <[email protected]> commit d039b811d62069194c5625117311e37edf825b50 Author: Bill Zissimopoulos <[email protected]> Date: Thu May 28 16:35:57 2020 -0700 mingw: lstat: compute correct size for symlinks This commit fixes mingw_lstat by computing the proper size for symlinks according to POSIX. POSIX specifies that upon successful return from lstat: "the value of the st_size member shall be set to the length of the pathname contained in the symbolic link not including any terminating null byte". Prior to this commit the mingw_lstat function returned a fixed size of 4096. This caused problems in git repositories that were accessed by git for Cygwin or git for WSL. For example, doing `git reset --hard` using git for Windows would update the size of symlinks in the index to be 4096; at a later time git for Cygwin or git for WSL would find that symlinks have changed size during `git status`. Vice versa doing `git reset --hard` in git for Cygwin or git for WSL would update the size of symlinks in the index with the correct value, only for git for Windows to find incorrectly at a later time that the size had changed. Signed-off-by: Bill Zissimopoulos <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit ff6e3753038838be224f2f0b38670ba9acb39df6 Author: Karsten Blees <[email protected]> Date: Sun May 24 01:24:41 2015 +0200 Win32: implement readlink() Implement readlink() by reading NTFS reparse points. Works for symlinks and directory junctions. If symlinks are disabled, fail with ENOSYS. Signed-off-by: Karsten Blees <[email protected]> commit 9b5c73a65f3670c13c1eabe119c0c89363ce6a0c Author: Karsten Blees <[email protected]> Date: Sun May 24 01:17:31 2015 +0200 Win32: mingw_chdir: change to symlink-resolved directory If symlinks are enabled, resolve all symlinks when changing directories, as required by POSIX. Note: Git's real_path() function bases its link resolution algorithm on this property of chdir(). Unfortunately, the current directory on Windows is limited to only MAX_PATH (260) characters. Therefore using symlinks and long paths in combination may be problematic. Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit 1c3cf1465db872d62cb260ee9a099aa8222578b1 Author: Karsten Blees <[email protected]> Date: Tue May 19 22:42:48 2015 +0200 Win32: mingw_rename: support renaming symlinks MSVCRT's _wrename() cannot rename symlinks over existing files: it returns success without doing anything. Newer MSVCR*.dll versions probably do not have this problem: according to CRT sources, they just call MoveFileEx() with the MOVEFILE_COPY_ALLOWED flag. Get rid of _wrename() and call MoveFileEx() with proper error handling. Signed-off-by: Karsten Blees <[email protected]> commit d241df32732a3e4c21b3465ac7f8905c9de12830 Author: Karsten Blees <[email protected]> Date: Sun May 24 01:06:10 2015 +0200 Win32: mingw_unlink: support symlinks to directories _wunlink() / DeleteFileW() refuses to delete symlinks to directories. If _wunlink() fails with ERROR_ACCESS_DENIED, try _wrmdir() as well. Signed-off-by: Karsten Blees <[email protected]> commit a6f791abafd69161cbb065ce8deeae68a0728223 Author: Karsten Blees <[email protected]> Date: Sat May 16 00:32:03 2015 +0200 Win32: add symlink-specific error codes Signed-off-by: Karsten Blees <[email protected]> commit b9a96819930b28bbba13267887871cbb843d4025 Author: Johannes Schindelin <[email protected]> Date: Fri Feb 23 02:50:03 2018 +0100 mingw (git_terminal_prompt): do fall back to CONIN$/CONOUT$ method To support Git Bash running in a MinTTY, we use a dirty trick to access the MSYS2 pseudo terminal: we execute a Bash snippet that accesses /dev/tty. The idea was to fall back to writing to/reading from CONOUT$/CONIN$ if that Bash call failed because Bash was not found. However, we should fall back even in other error conditions, because we have not successfully read the user input. Let's make it so. Signed-off-by: Johannes Schindelin <[email protected]> commit d8e8d4805d6469ed3e3c9e7d4404cb42414f0caf Author: Karsten Blees <[email protected]> Date: Sun May 24 01:55:05 2015 +0200 Win32: change default of 'core.symlinks' to false Symlinks on Windows don't work the same way as on Unix systems. E.g. there are different types of symlinks for directories and files, creating symlinks requires administrative privileges etc. By default, disable symlink support on Windows. I.e. users explicitly have to enable it with 'git config [--system|--global] core.symlinks true'. The test suite ignores system / global config files. Allow testing *with* symlink support by checking if native symlinks are enabled in MSys2 (via 'MSYS=winsymlinks:nativestrict'). Reminder: This would need to be changed if / when we find a way to run the test suite in a non-MSys-based shell (e.g. dash). Signed-off-by: Karsten Blees <[email protected]> commit 88e607cab871f5740cee61723ceadcaeadf17c4f Author: Karsten Blees <[email protected]> Date: Tue May 19 21:48:55 2015 +0200 Win32: factor out retry logic The retry pattern is duplicated in three places. It also seems to be too hard to use: mingw_unlink() and mingw_rmdir() duplicate the code to retry, and both of them do so incompletely. They also do not restore errno if the user answers 'no'. Introduce a retry_ask_yes_no() helper function that handles retry with small delay, asking the user, and restoring errno. mingw_unlink: include _wchmod in the retry loop (which may fail if the file is locked exclusively). mingw_rmdir: include special error handling in the retry loop. Signed-off-by: Karsten Blees <[email protected]> commit 8c63e2136907ad6472b3cbd98456735f0973d217 Author: Karsten Blees <[email protected]> Date: Sat May 16 01:11:37 2015 +0200 Win32: lstat(): return adequate stat.st_size for symlinks Git typically doesn't trust the stat.st_size member of symlinks (e.g. see strbuf_readlink()). However, some functions take shortcuts if st_size is 0 (e.g. diff_populate_filespec()). In mingw_lstat() and fscache_lstat(), make sure to return an adequate size. The extra overhead of opening and reading the reparse point to calculate the exact size is not necessary, as git doesn't rely on the value anyway. Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit fce1ceb95c9267bec3ec05eb376ba9e792d60202 Author: Karsten Blees <[email protected]> Date: Tue Jan 10 23:21:56 2017 +0100 mingw: teach fscache and dirent about symlinks Move S_IFLNK detection to file_attr_to_st_mode() and reuse it in fscache. Implement DT_LNK detection in dirent.c and the fscache readdir version. Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit d90d4afa7220a16ef2628b1449f5d91d43c7329c Author: Karsten Blees <[email protected]> Date: Sun May 24 00:17:56 2015 +0200 Win32: let mingw_lstat() error early upon problems with reparse points When obtaining lstat information for reparse points, we need to call FindFirstFile() in addition to GetFileInformationEx() to obtain the type of the reparse point (symlink, mount point etc.). However, currently there is no error handling whatsoever if FindFirstFile() fails. Call FindFirstFile() before modifying the stat *buf output parameter and error out if the call fails. Note: The FindFirstFile() return value includes all the data that we get from GetFileAttributesEx(), so we could replace GetFileAttributesEx() with FindFirstFile(). We don't do that because GetFileAttributesEx() is about twice as fast for single files. I.e. we only pay the extra cost of calling FindFirstFile() in the rare case that we encounter a reparse point. Note: The indentation of the remaining reparse point code will be fixed in the next patch. Signed-off-by: Karsten Blees <[email protected]> commit 730279b83dea7c4fd91a6a905ca48966c5679bab Author: Karsten Blees <[email protected]> Date: Tue May 12 00:58:39 2015 +0200 Win32: remove separate do_lstat() function With the new mingw_stat() implementation, do_lstat() is only called from mingw_lstat() (with follow == 0). Remove the extra function and the old mingw_stat()-specific (follow == 1) logic. Signed-off-by: Karsten Blees <[email protected]> commit e404d24d78940c9682f0e66ef7d2e68a26c8b90f Author: Karsten Blees <[email protected]> Date: Sat May 16 01:18:14 2015 +0200 Win32: implement stat() with symlink support With respect to symlinks, the current stat() implementation is almost the same as lstat(): except for the file type (st_mode & S_IFMT), it returns information about the link rather than the target. Implement stat by opening the file with as little permissions as possible and calling GetFileInformationByHandle on it. This way, all link resoltion is handled by the Windows file system layer. If symlinks are disabled, use lstat() as before, but fail with ELOOP if a symlink would have to be resolved. Signed-off-by: Karsten Blees <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> commit bf011e9eec04507605c77f7a826164bfe1ec2d98 Author: Karsten Blees <[email protected]> Date: Tue May 12 11:09:01 2015 +0200 Win32: don't call GetFileAttributes twice in mingw_lstat() GetFileAttributes cannot handle paths with trailing dir separator. The current [l]stat implementation calls GetFileAttributes twice if the path has trailing slashes (first with the original path passed to [l]stat, and and a second time with a path copy with trailing '/' removed). With Unicode conversion, we get the length of the path for free and also have a (wide char) buffer that can be modified. Remove trailing directory separators before calling the Win32 API. Signed-off-by: Karsten Blees <[email protected]> commit 743fbb109b9f674eee17e4743b54ec068dff9bd9 Author: Karsten Blees <[email protected]> Date: Mon May 11 19:58:14 2015 +0200 lockfile.c: use is_dir_sep() instead of hardcoded '/' checks Signed-off-by: Karsten Blees <[email protected]> commit cae0ed2b69fc4cc92fbc0a209d69b76d593be9a9 Author: Karsten Blees <[email protected]> Date: Mon May 11 22:15:40 2015 +0200 strbuf_readlink: support link targets that exceed PATH_MAX strbuf_readlink() refuses to read link targets that exceed PATH_MAX (even if a sufficient size was specified by the caller). As some platforms support longer paths, remove this restriction (similar to strbuf_getcwd()). Signed-off-by: Karsten Blees <[email protected]> commit ab6cf4a85e9eb7feb01e9835b12a63ee88c7b502 Author: Karsten Blees <[email protected]> Date: Mon May 11 19:54:23 2015 +0200 strbuf_readlink: don't call readlink twice if hint is the exact link size strbuf_readlink() calls readlink() twice if the hint argument specifies the exact size of the link target (e.g. by passing stat.st_size as returned by lstat()). This is necessary because 'readlink(..., hint) == hint' could mean that the buffer was too small. Use hint + 1 as buffer size to prevent this. Signed-off-by: Karsten Blees <[email protected]> commit 0987f685d16c047ccb9e317857339812ab1255c7 Author: Ben Boeckel <[email protected]> Date: Fri Apr 22 09:06:23 2022 -0400 clean: suggest using `core.longPaths` if paths are too long to remove On Windows, git repositories may have extra files which need cleaned (e.g., a build directory) that may be arbitrarily deep. Suggest using `core.longPaths` if such situations are encountered. Fixes: #2715 Signed-off-by: Ben Boeckel <[email protected]> commit 29f7afc8f88a589928379298c56bf527ad10185a Author: Jeff Hostetler <[email protected]> Date: Fri Mar 25 16:56:04 2022 -0400 compat/fsmonitor/fsm-*-win32: support long paths Update wchar_t buffers to use MAX_LONG_PATH instead of MAX_PATH and call xutftowcs_long_path() in the Win32 backend source files. Signed-off-by: Jeff Hostetler <[email protected]> commit b8923c8fba0c566a57bd7192f41df8f6f666c1dc Author: Johannes Schindelin <[email protected]> Date: Wed Sep 6 09:14:47 2023 +0200 win32(long path support): leave drive-less absolute paths intact When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes https://github.com/git-for-windows/git/issues/4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gm…

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho requested a review from whoisj May 18, 2017 13:54

whoisj approved these changes May 18, 2017

View reviewed changes

dscho mentioned this pull request May 18, 2017

Ctrl+C revisited git-for-windows/msys2-runtime#15

Merged

dscho force-pushed the mingw-kill-process branch from a4d9351 to 4828f51 Compare May 18, 2017 18:55

whoisj reviewed May 18, 2017

View reviewed changes

jeffhostetler reviewed May 18, 2017

View reviewed changes

compat/mingw.c Outdated

}

errno = err_win_to_posix(GetLastError());

ret = exit_process(h, 3);

This comment was marked as off-topic.

Sign in to view

This comment was marked as off-topic.

Sign in to view

This comment was marked as off-topic.

Sign in to view

dscho force-pushed the mingw-kill-process branch from 4828f51 to 175b6ce Compare May 18, 2017 21:10

jeffhostetler reviewed May 18, 2017

View reviewed changes

compat/win32/exit-process.h

if (!initialized) {

HINSTANCE kernel32 = GetModuleHandle("kernel32");

if (!kernel32)

die("BUG: cannot find kernel32");

This comment was marked as off-topic.

Sign in to view

This comment was marked as off-topic.

Sign in to view

dscho force-pushed the mingw-kill-process branch from 175b6ce to 25fc3f6 Compare May 19, 2017 09:18

dscho force-pushed the mingw-kill-process branch from 25fc3f6 to 5d1a26c Compare May 19, 2017 10:17

dscho force-pushed the mingw-kill-process branch from 5d1a26c to 780800b Compare May 19, 2017 11:08

dscho merged commit 80a6209 into git-for-windows:master May 19, 2017

dscho deleted the mingw-kill-process branch May 19, 2017 13:12

git-for-windows-ci pushed a commit that referenced this pull request May 23, 2017

Merge pull request #1170 from dscho/mingw-kill-process

a027d2c

Handle Ctrl+C in Git Bash nicely

git-for-windows-ci pushed a commit that referenced this pull request May 23, 2017

Merge pull request #1170 from dscho/mingw-kill-process

2860b93

Handle Ctrl+C in Git Bash nicely

dscho added a commit that referenced this pull request May 29, 2017

Merge pull request #1170 from dscho/mingw-kill-process

0342957

Handle Ctrl+C in Git Bash nicely

dscho added a commit that referenced this pull request May 29, 2017

Merge pull request #1170 from dscho/mingw-kill-process

03b3bdb

Handle Ctrl+C in Git Bash nicely

dscho added a commit that referenced this pull request May 29, 2017

Merge pull request #1170 from dscho/mingw-kill-process

1d54978

Handle Ctrl+C in Git Bash nicely

dscho added a commit that referenced this pull request May 30, 2017

Merge pull request #1170 from dscho/mingw-kill-process

2dd2cb9

Handle Ctrl+C in Git Bash nicely

git-for-windows-ci pushed a commit that referenced this pull request Oct 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

b47343b

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

8b338a6

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

e06aa1b

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

ce46227

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

2c1439b

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit that referenced this pull request Oct 23, 2024

Merge pull request #1170 from dscho/mingw-kill-process

34e5100

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

895effd

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

6e4cdd2

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

9facbbb

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Oct 30, 2024

Merge pull request #1170 from dscho/mingw-kill-process

8ff4904

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 1, 2024

Merge pull request #1170 from dscho/mingw-kill-process

3accd13

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 6, 2024

Merge pull request #1170 from dscho/mingw-kill-process

b85b501

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit that referenced this pull request Nov 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

6174c3a

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit that referenced this pull request Nov 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

699f036

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit that referenced this pull request Nov 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

a42e633

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit that referenced this pull request Nov 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

80801cc

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit that referenced this pull request Nov 22, 2024

Merge pull request #1170 from dscho/mingw-kill-process

0365608

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

ef2cc97

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

48bfd48

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

d88c3b1

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

2e37b7b

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit to dscho/git that referenced this pull request Nov 25, 2024

Merge pull request git-for-windows#1170 from dscho/mingw-kill-process

86602ba

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Nov 25, 2024

Merge pull request #1170 from dscho/mingw-kill-process

7bcb561

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit to dscho/git that referenced this pull request Dec 16, 2024

Merge pull request git-for-windows#1170 from dscho/mingw-kill-process

5c4b21a

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit to dscho/git that referenced this pull request Dec 16, 2024

Merge pull request git-for-windows#1170 from dscho/mingw-kill-process

d465182

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit to dscho/git that referenced this pull request Dec 16, 2024

Merge pull request git-for-windows#1170 from dscho/mingw-kill-process

8ec8df5

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

dscho added a commit to dscho/git that referenced this pull request Dec 17, 2024

Merge pull request git-for-windows#1170 from dscho/mingw-kill-process

46b4a0c

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Dec 17, 2024

Merge pull request #1170 from dscho/mingw-kill-process

c19e942

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

git-for-windows-ci pushed a commit that referenced this pull request Dec 19, 2024

Merge pull request #1170 from dscho/mingw-kill-process

1c14a86

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle Ctrl+C in Git Bash nicely #1170

Handle Ctrl+C in Git Bash nicely #1170

dscho commented May 18, 2017

whoisj left a comment •

edited

Loading

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

dscho commented May 18, 2017

whoisj commented May 18, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

jeffhostetler commented May 18, 2017

dscho commented May 18, 2017

dscho commented May 18, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

whoisj commented May 19, 2017

dscho commented May 19, 2017

dscho commented May 19, 2017

Handle Ctrl+C in Git Bash nicely #1170

Handle Ctrl+C in Git Bash nicely #1170

Conversation

dscho commented May 18, 2017

whoisj left a comment • edited Loading

Choose a reason for hiding this comment

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

dscho commented May 18, 2017

whoisj commented May 18, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

jeffhostetler commented May 18, 2017

dscho commented May 18, 2017

dscho commented May 18, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

whoisj commented May 19, 2017

dscho commented May 19, 2017

dscho commented May 19, 2017

whoisj left a comment •

edited

Loading