Git add and checkout interactive broken possibly neovim related

[gotnone]

Description / Steps to reproduce the issue

Interactive git commands with the -p patch option freeze / halt / lock up after using a terminal for a while. Initial attempts seem to be successful after opening up a new ucrt64 session, but after some time these commands no longer work correctly. The issue is exposed rather quickly if I edit some files in neovim in the terminal.

1. Start an msys2 ucrt64 mintty terminal
2. edit some files using neovim
3. close neovim
4. attempt to git add -p or git checkout -p
5. The first attempt or two may be successful
6. edit some files again in neovim
7. close neovim
8. attempt to git add -p or git checkout -p
9. At the prompt to add / discard a hunk, pressing any key and then enter causes the git command to freeze / hang
10. press Ctrl-C to regain access to the terminal

git version: git version 2.47.1
pacman version: Pacman v6.1.0 - libalpm v14.0.0
msys2-runtime version: 3.5.4-8

I have noticed this issue with the prior git version 2.47.0-1 as well.

Expected behavior

I expect that when using git with interactive commands to be able to successfully pass input to git and to have it continue through the interactive process without locking up.

I expect to be able to open a neovim editor and make changes in a terminal without making git interactive commands lock up afterwards.

Actual behavior

After a certain indeterminate amount of interaction with a ucrt64 mintty terminal attempts to use git with -p --patch interactive commands do not work correctly and the interface freezes after supplying user input.

I can not say that the cause is isolated to using neovim on the same terminal, but that is what triggers the issue the quickest in my experience.

Once this begins all subsequent attempts to use git -p commands fail in a similar manner. Pressing Alt-F2 to spawn a new terminal will resolve the issue in the new terminal. However, editing a file with neovim and then attempting to use a git interactive command will cause the problem to appear in the new terminal as well. The problem remains until the ucrt64 window is closed.

An additional strange thing that I have noticed is that once the git interactive commands start to fail / lock up, some other commands start to lock up in the same terminal. Specifically, the pacman -S some_package command locks up after prompting for confirmation of the install.

Attempting to see what is happening by running strace -w git add -p seems to bypass whatever was causing the issue, but it does this by spawning a new terminal window. Is there a better way to use strace or some other tool to determine where git is getting stuck?

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-19045

Are you willing to submit a PR?

No response