Interactive staging sometimes freezes the prompt

[forgetaboutit]

• [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 --build-options

git version 2.39.2.windows.1
cpu: x86_64
built from commit: a82fa99b36ddfd643e61ed45e52abe314687df67
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19045.2604]

• What options did you set as part of the installation? Or did you choose the defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Rebase
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

Details

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

Running Git in Windows Terminal and PowerShell 7.3.2

• What commands did you run to trigger this issue? If you can provide a Minimal, Complete, and Verifiable example this will help us understand the issue.

# I can't provide a reliable repro. This only happens occasionally:
git add -p someSpecificFile

# Interactively:
> (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? e
> Edit hunk in Vim, exit with `:x`

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

The next unstaged hunk is shown and I'm asked for input. I should be able to proceed with the next hunk without issues.

• What actually happened instead?

The next unstaged hunk is shown and I'm asked for input. However, the interactive prompt is completely stuck. Ctrl + C or q don't help. When I kill the tab in Windows Terminal and reopen it, I could reproduce the issue reliably this time. On different occasions reopening the tab fixed the issue and I was able to proceed with the next hunk.

• If the problem was occurring with a specific repository, can you provide the URL to that repository to help us with testing?

Unfortunately the code is proprietary.

I have attached two zipped mini dump files with full memory for the processes. I'm unsure which process actually gets stuck. A screenshot from the "Analyze wait chain" command from the task manager seems to hint at one waiting for the other.

git frozen interactive staging.zip

Edit: To clarify, this issue doesn't only happen when editing hunks. It also occurs during regular "y"/"n" staging without using Vim.

[dscho]

Please test the latest snapshot. There has been a bug fix about a hang in the MSYS2 runtime which I suspect might be at play here, too.

[forgetaboutit]

@dscho Will do.

Just a minor hint: The snapshot advertises itself at Git 2.39.1.windows.1.538.g8c4b3e3471.20230222091340 while the most recent version seems to be 2.39.2 at the moment. It's entirely possible I'm missing something but I'd expect it showing up as Git 2.39.2.windows....

Edit: The aforementioned snapshot unfortunately still exhibits the issue. Is there anything I can do to help?

[dscho]

The snapshot advertises itself at Git 2.39.1.windows.1.538.g8c4b3e3471.20230222091340 while the most recent version seems to be 2.39.2 at the moment.

Yes, that is because v2.39.2.windows.1 has not yet been merged into the main branch.

When I load the .dmp file into a WinDbg session with the corresponding .pdb from https://github.com/git-for-windows/git/releases/download/v2.39.2.windows.1/pdbs-for-git-64-bit-2.39.2.1.a82fa99b36-1.zip added to the .sympath, I see this stack in the first thread:

[0x0]   ntdll!NtReadFile + 0x14   
[0x1]   KERNELBASE!ReadFile + 0x73   
[0x2]   msvcrt!read_nolock + 0x2b2   
[0x3]   msvcrt!read + 0xbb   
[0x4]   msvcrt!filbuf + 0x92   
[0x5]   msvcrt!fgetc + 0x103   
[0x6]   git!strbuf_getwholeline + 0x7c   
[0x7]   git!strbuf_getline + 0x15   
[0x8]   git!git_read_line_interactively + 0x2e   
[0x9]   git!run_add_p + 0xd76   
[0xa]   git!run_add_interactive + 0x10a   
[0xb]   git!cmd_add + 0x715   
[0xc]   git!handle_builtin + 0x20e   
[0xd]   git!cmd_main + 0x196   
[0xe]   git!main + 0xc5   
[0xf]   git!wmain + 0x2c6   
[0x10]   git!__tmainCRTStartup + 0x16f   
[0x11]   git!mainCRTStartup + 0x16   
[0x12]   kernel32!BaseThreadInitThunk + 0x14   
[0x13]   ntdll!RtlUserThreadStart + 0x21   

That would indicate that Git is waiting for input. I see only benign things going on here.

[dscho]

I think that I've hit the same issue, but only when running git add -p from within a Git Bash VS Code's Terminal and when I use e with VS Code as the editor. Curious. I don't have time to look into this, at least not this and the next week, but I wanted to leave this crumb here in case somebody else has a look.

[lucax88x]

this appens also on a macos and I noticed it happens when you enable line-numbers=true

without this flag it's immediate.

[zwassall-globus]

I have observed this issue in the following versions:

1. 2.39.2
2. 2.38.1
3. 2.37.3
4. 2.37.0

I have not observed this issue in the following versions:

1. 2.36.1

So it appears that the issue was introduced between 2.36.1 and 2.37.0. I haven't tested 2.36.2, the only other released version between those two. It seems more likely to me that this bug was introduced in the more significant (if version numbers are to be believed) 2.37.0 than in 2.36.2.

[imbrish]

This problem occurs reliably for me with the following in git config:

[interactive]
    diffFilter = delta --color-only
[alias]
    ap = "!git add -p"

In git-cmd the keyboard input does not work at all when git ap (alias) asks:

(1/1) Stage this hunk [y,n,q,a,d,e,?]?

The Ctrl + C does nothing, the only way to stop is with Ctrl + Z.

Actually, it seems not the input is broken, but the output. I am still able to go through the git add --patch in blind, and the changes do get staged. This is made even more apparent by using ctrl + enter which will show the missing prompts.

Everything works fine with either of the changes below:

[interactive]
    diffFilter = diff-so-fancy --patch

[interactive]
    diffFilter = delta --color-only | cat

[alias]
    ap = add -p

The problem does not occur for me in git-bash (MINGW64/MinTTY). Tested with Git 2.44.0.windows.1, Windows 10.0.19045.4170. Other delta users reported the same problem in Git Bash under Windows Terminal 1.19.10573.0. But using the same configuration with git version 2.44.0 (from MSYS2/MINGW64) works as expected.

I have also experienced a possibly related issue: textconv set to shell command (with !) breaks mouse scrolling in diffs when pager is set to less. I am not entirely sure what happens there, but it seems to have something to do with registering of mouse and keyboard hooks.

See also https://github.com/dandavison/delta/issues/1650.

[Uxorious]

This is suddenly happening for me as well (2.44.0.windows.1 running within Bash in the latest Windows Terminal). It's worked fine for a long time, and I haven't updated anything except Windows and other programs. After a reboot it seems to work fine, and then suddenly it stops working.

[dscho]

Could you please test with Git for Windows v2.47.0-rc0? It comes with a new MSYS2 runtime version that I hope fixes this (in my tests, it did).

[imbrish]

Git v2.47.0-rc0 did not fix the problem in git-cmd for me. The keyboard input is still frozen, now I am no longer able to progress "in blind" - the results seem erratic.