interactive.singlekey in git-cmd.exe lists chunks thrice in 2.37.0-rc0 and later

[mataha]

• I was not able to find an open or closed issue matching what I'm seeing (and believe me, I tried)

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.41.0.windows.1
cpu: x86_64
built from commit: ff94e79c4724635915dbb3d4ba38f6bb91528260
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.2965]

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

$ type "C:\Program Files\Git\etc\install-options.txt"

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

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

None. I'm stumped.

Details

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

conhost.exe + cmd.exe. Tested other configurations; works (i.e. doesn't) the same everywhere.

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

$ git config --global interactive.singlekey true
$ git add --patch

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

Interactive selection of chunks using a single key, i.e. without supplying linefeed.

• What actually happened instead?

Nothing happens when a key is pressed. Upon pressing Enter, the listing gets printed thrice.

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

The problem is not related to a specific repository.

So far I've tested 2.36.1-64-bit (works correctly) and 2.41.0-64-bit (see below), regular installers and PortableGit. I have yet to narrow the version which introduced this regression.

As they say - a picture (well, a clip) is worth a thousand words:

cmd_CqNU48rMxW.mp4

[mataha]

During this weekend I was able to test things thoroughly:

• 2.36.1 is the last version that works correctly
• 2.37.0-rc0 and later all exhibit erroneous behaviour

The preliminary culprit is MSYS2 runtime (Cygwin 3.3.5 - possibly something in fhandler_console::set_input_mode() or other machinery tinkering with console mode), but I'm not sure yet.

Additional observations:

• 2.36.1: git add --patch results in a very noticeable delay before the first chunk gets shown;
  this delay is present in git-bash.exe, git-cmd.exe and during regular terminal usage
• 2.37.0-rc0 to 2.40.1: git-bash.exe works properly and lists the first chunk immediately for some reason; git-cmd.exe breaks
• 2.41.0-rc0.windows.1 and later: git-bash.exe stops working

[ParkerM]

I've observed the same behavior on 2.41.0.windows.3 through Git Bash via Windows Terminal and MSYS2 mintty, where hunks show up 3 times and interactive.singleKey seems to be ignored.

Here's some other curious behavior which may be related to your second bullet point: When you get the 3x hunk view, input 2 options (e.g. ny<enter>). When enter is pressed, the n is applied and the first hunk is skipped, then the y is automatically applied and the subsequent hunk is staged. You can also try with a bunch of characters like nnnnnnnnn<enter> and it'll just keep going once you press enter until each input is done or the hunks are exhausted.

Upon further testing, it seems like everything after the first character is flushed one by one until all hunks are exhausted. Then on the next git add -p, it continues to automatically apply the remaining buffered inputs until no characters are left.
(Fake edit: well, now I can't reproduce this any more)

---

Some examples (noise ommitted with ...). Note the lines immediately after the prompts that contain the input or an empty line (or lack thereof)

Just pressing ?<enter> which should bring up the help menu..

(1/1) Stage this hunk [y,n,q,a,d,e,?]? ?<enter>
?
...(help menu)
(1/1) Stage this hunk [y,n,q,a,d,e,?]?
...(help menu)
(1/1) Stage this hunk [y,n,q,a,d,e,?]?

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

With 2 inputs:

(1/1) Stage this hunk [y,n,q,a,d,e,?]? ??<enter>
?
...(help menu)
(1/1) Stage this hunk [y,n,q,a,d,e,?]? ?
...(help menu)
(1/1) Stage this hunk [y,n,q,a,d,e,?]?
...(help menu)
(1/1) Stage this hunk [y,n,q,a,d,e,?]?

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

Just hitting enter

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

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

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

While goofing around with just pressing enter, I noticed that a newline only intermittently appears between the prompt and the help text. Perhaps this intermittent-ness explains the nature of the bug, and why I can't reliable reproduce the behavior where the buffer continues flushing on a subsequent git add -p. Almost like it's trying to capture then simulate the actual input, and in doing so hits a race condition against itself.

[Yankes]

I have same issue with interactive.singleKey, its not handled correctly.
As far I understand this problem with new buldin version, older perl version work correclty.
For now I hack this by restoring:
https://github.com/jakebailey/git-for-windows/blob/a6a323b31e2bcbac2518bddec71ea7ad558870eb/git-add--interactive.perl
To home directory and then calling it by:

PERLLIB=/mingw64/share/perl5 ~/git-add--interactive.perl --patch=checkout HEAD --

I think that cygwin is in fault as it own git have broken singleKey too:
cygporter/git#57