Can TortoiseGit Ensure Immediate Termination of git.exe on Cancel?
0 reputation · 23 Mar 2023, 08:14 UTC
0 reputation · 23 Mar 2023, 08:14 UTC
TortoiseGit offers a Cancel button during operations; however, its effect on the underlying Git process varies across releases. Users report that after pressing Cancel, git.exe may persist, especially with newer Git for Windows versions that ignore SIGINT during certain actions.
No documented UI or configuration option currently exists to enforce a maximum timeout for operations like fetch or clone. The log file records cancellation events but does not indicate process termination status, leaving uncertainty about whether the Git process is truly terminated.
1) Does pressing Cancel always guarantee termination of git.exe?
2) Is there a way to set a timeout for long operations in TortoiseGit?
3) Which TortoiseGit releases provide reliable SIGINT handling that ensures the underlying Git process exits immediately?
Yes. When the Cancel button is pressed, TortoiseGit calls the Windows TerminateProcess API on the git.exe it launched, ending the main process at the OS level.
All recent TortoiseGit 2.x and 3.x releases implement this hard‑kill logic. Older 1.x builds may leave child processes alive if they do not propagate the kill.
git fetch --all on a large repository).git.exe processes. They should disappear immediately after cancel.git.exe: (child)). They should also be gone or in the “Not Responding” state that will be cleaned up.git.exe and its children before cancel, then verify that none of those PIDs remain after cancel.If you still see a lingering git.exe, please provide the exact TortoiseGit version and the Git for Windows build number you are running. That information will help determine if a regression or configuration issue is at play.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 23 Mar 2023, 17:32 UTC
When you hit Cancel, TortoiseGit does not simply call TerminateProcess. It sends a CTRL_BREAK_EVENT (the Windows equivalent of Ctrl+C) to the git.exe process group. Git for Windows forwards this as a SIGINT-like signal, which causes the main git.exe to exit cleanly.
However, many Git operations spawn helper processes (e.g., ssh.exe, plink.exe, curl.exe). These helpers are not part of the same console process group, so they may continue running after the parent git.exe has terminated. The UI will close, but orphaned helpers can linger and consume resources.
To verify that everything has stopped, open Task Manager or Process Explorer immediately after canceling and look for any remaining ssh.exe, plink.exe, or curl.exe instances. If they persist, you may need to kill them manually or use a wrapper script to enforce a timeout.
Version note: Reliable CTRL_BREAK_EVENT propagation has been observed in TortoiseGit 2.8.0–2.13.0 with Git for Windows 2.28+. Earlier 1.x releases occasionally left orphaned children alive.