git version 2.16.1.windows.4
cpu: x86_64
built from commit: ef6d451bbfef86a529ebf12620289e0f15a93d8e
sizeof-long: 4
Microsoft Windows [Version 10.0.16299.192]
Editor Option: Notepad++
Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
MSYS2/mingw-w64 installed on system (problem persists when it's excluded from PATH, though)
Git Bash
git shortlog -s
(more than one page of output so it pauses)
Exit with "Ctrl+C" instead of "Q"
Command interrupted, normal operation of shell restored.
Command interrupted, shell in an unusable state:
Upstream MSYS2-git is not affected:
Thank you for your bug report.
Linux behavior in this case would not actually be to quit the pager, but to kill just git and keep the pager running until q was pressed.
This should be the behavior we want to imitate (but I guess we kill the pager, too...)
As a workaround for you, to get your terminal functional again: call reset
I'm seeing this issue in Windows 10 as well. Git-2.16.2-64-bit
Latest public Windows 10 updates installed.
This kills my Git Bash productivity when diff'ing files before checkin.
Hope ya'll can fix this soon. Thank you
@jefhai to get you unblocked, just reinstall Git for Windows and select "ConHost" instead of "MinTTY" as Git Bash's terminal.
Thank you @dscho !
Hi all,
As mentioned on stackoverflow, a reset command will work around the issue, but my experience is a little uncomfortable as it appears to be a fairly significant terminal reset. I'm not sure what, if anything, is also reset in the process.
https://stackoverflow.com/questions/44281617/git-text-invisible
A Linux friend gave me another command, stty echo, which also restores the echo for me, and it appears much less intrusive to the console operation.
Again, in this context, the difference in using the two commands may be little or none, but psychologically the latter _feels_ more comforting to me.
Cheers,
dVt
FWIW I did work three full days this week on fixing this, and I got stuck on the issue where something in the MSYS2 runtime decides to kill a less.exe when spawned from a git.exe (with stdout of the latter connected to the stdin of the former) when the latter goes away.
I will have to figure out a minimal reproducer and then ask on the Cygwin mailing list whether anybody can help me figure this out.
This is the current state of affairs: https://github.com/git-for-windows/msys2-runtime/compare/master...dscho:ctrl-c-with-CtrlRoutine
@dieselVtwin Feel free to build the MSYS2 runtime based on this branch and test.
The newest snapshot at https://wingit.blob.core.windows.net/files/index.html should fix this. Please test.
I am still experiencing this in VS Code in Windows.
Got here from this issue: https://github.com/Microsoft/node-pty/issues/7
Wiped Git for Windows completely (like even manually went through the registry and removed it.
Wiped all the caches for VS Code and disabled all extensions, removed setting for Git Bash to be default terminal.
Restarted.
Reinstalled this build: Thu, 3 May 2018 12:46:36 +0200
(commit 05ca542f78) from here: https://wingit.blob.core.windows.net/files/index.html
No change.
I am able to reproduce this consistently by attempting a Git connection that requires password input, then hitting Ctrl C when prompted for the password. I usually have key authentication setup so when I get prompted for a password, I know I haven't setup a key yet for that user (I admin a bunch of private repos within our organization).
Ctrl C will kick you back to the bash prompt (or so it seems) but if you type anything, it continues on like you provided the wrong password and goes back into the password prompt loop - again, this is AFTER already having displaying the bash prompt again.
If you just enter through, this you get to the "real" bash prompt again, but whatever you type is invisible - that is, it's registered (like if you type exit, it exits) but you can't see it.
This doesn't happen directly in Git Bash itself, only from within VS Code.
According to the issue I linked to above, this is a Git Bash issue. Not sure, but it doesn't happen with the same actions when using PowerShell as the terminal.
@methodbox when you call this with GIT_TRACE=1 set, do you see some command-line containing read -r -s line </dev/tty? If so, then the culprit is this code: https://github.com/git-for-windows/git/blob/e7621d891d081acff6acd1f0ba6ae0adce06dd09/compat/terminal.c#L113-L165
In that case, I could imagine that prefixing the string in line 121 with something like trap \"stty echo\" SIGINT && could solve your problem.
Why not give it a try?
Sorry late reply - just saw this.
I鈥檒l give it a shot and report back.
Actually I just realized I鈥檓 not quite sure how to do what you鈥檙e asking.
I don鈥檛 know C well - more of a JS guy.
Can you give me some guideance here?
@methodbox first, install the Git for Windows SDK. Then, run sdk cd git and change the respective line as I indicated earlier. Then, run sdk install git and perform whatever test you have to reproduce the bug.
I am experiencing the same problem, when I press CTRL+C, the editor unexpectedly quits, appears 3221225786, my solution is to upgrade the git tool, the following is my git version
git --version
// git version 2.23.0.windows.1
The issue has been resolved after the upgrade
Most helpful comment
Thank you for your bug report.
Linux behavior in this case would not actually be to quit the pager, but to kill just git and keep the pager running until
qwas pressed.This should be the behavior we want to imitate (but I guess we kill the pager, too...)
As a workaround for you, to get your terminal functional again: call
reset