Git: Interrupting git with "Ctrl+C" renders Git Bash unusable (input not printed anymore)

Created on 11 Feb 2018  路  12Comments  路  Source: git-for-windows/git

  • [x] I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
git version 2.16.1.windows.4
cpu: x86_64
built from commit: ef6d451bbfef86a529ebf12620289e0f15a93d8e
sizeof-long: 4
  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
Microsoft Windows [Version 10.0.16299.192]
  • What options did you set as part of the installation? Or did you choose the
    defaults?
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
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

MSYS2/mingw-w64 installed on system (problem persists when it's excluded from PATH, though)

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Git Bash

git shortlog -s

(more than one page of output so it pauses)

Exit with "Ctrl+C" instead of "Q"

  • What did you expect to occur after running these commands?

Command interrupted, normal operation of shell restored.

  • What actually happened instead?

Command interrupted, shell in an unusable state:

  • User input is not printed to shell anymore.
  • In the background characters still seem to be typed, though, as entering something an pressing enter still results in output.
  • I did not find a ways to restore normal operation without closing and reopening Git Bash

Upstream MSYS2-git is not affected:

  • "Ctrl+C" has no effect
  • "Ctrl+Z" aborts the command properly (functionality of Bash restored)
    This shortcut has no function in Git Bash, though.
bug msys2

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

All 12 comments

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

Was this page helpful?
0 / 5 - 0 ratings