Fix console mode restoring #87
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
This was referenced Mar 3, 2025
Open
|
/open pr The workflow run was started |
The required console mode for a non-cygwin process is different from that for a cygwin process. There are currently three modes: tty::cygwin, tty::native, and tty::restore. The latter two are for the non-cygwin processes. tty::restore is the mode for the non-cygwin processes that started the cygwin process, used to restore the previous behaviour. tty::native is the mode that reflects some terminfo flags. The issue below is caused because the console mode fails to be restored to the previous console mode used by cmd.exe. This patch redesigns the strategy to determine which mode should be set on console close() to fix all similar problems. Previously, the number of handle count is used to determine the appropriate console mode. However, the handle count seems uncertain for that purpose. In the new design, the relation ship between the master process and the process that is about to close the console is mainly used. This can provide more certain result than previous one. Addresses: microsoft/git#730 Backported-from: 3312f2d (Cygwin: console: Redesign mode set strategy on close()., 2025-03-03) Fixes: 30d2669 ("Cygwin: console: Fix clean up conditions in close()") Reported-by: Mike Marcelais, Johannes Schindelin <[email protected]> Signed-off-by: Takashi Yano <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
fix-non-cygwin-console-mode-on-close
branch
from
f551f2a to
463ebcd
Compare
|
/open pr The workflow run was started |
github-actions bot
pushed a commit
to git-for-windows/build-extra
that referenced
this pull request
Mar 3, 2025
A bug has been [fixed](git-for-windows/msys2-runtime#87) that, when calling `git add -p` from VS Code's internal terminal, after using the `e`dit command, caused [the internal terminal got stuck](git-for-windows/git#4776) and no further command was accepted. Signed-off-by: gitforwindowshelper[bot] <[email protected]>
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.
Under certain circumstances, when a non-MSYS process is spawned from an MSYS process that is spawned from a non-MSYS process that is spawned from an MSYS process, the console state can get corrupted by the MSYS2 runtime.
This is the case, for example, when spawning a background process that outputs to
stdoutfrom a Git hook.This behavior is inherited from the Cygwin runtime which allows the same symptom to be reproduced as long as one is careful enough to force
git.exeto use Cygwin's Bash to run its hooks.The Cygwin core developer who is the only person to understand Cygwin's pseudo console handling was kind enough to fix this problem, and I backported it to the MSYS2 runtime v3.5.7.
This closes microsoft/git#730.
This closes git-for-windows/git#4776.