To be clear, I did close the editor, at which point Git Bash shows me the next diff and asks me to choose an option (y, n, a, d, ...). It's at that point the keyboard is unresponsive. Not while the editor is still open. If it matters, I'm using Notepad++ as the editor. On Wed, Apr 24, 2024 at 5:23 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > Using the "e" option should invoke your editor and wait until it exits. > > The only way Git has to know that you're done editing is that the editor > > process it invokes has exited. > > Whichever editor was launched, unless the user explicitly said the hint > is not necessary by setting advice.waitingForEditor to false, the code > should have given something like this: > > hint: Waiting for your editor to close the file... > > so ... > > > What does "git var GIT_EDITOR" at a Git Bash prompt print? If you have > > your editor configured to open in an existing editor window, does > > closing the new editor tab or window that Git causes to be opened fix > > the problem? > > ... I would expect that there may be something more than a silly > "the editor is running elsewhere and the user is stuck, expecting > something to happen but the editor is waiting for the user" problem > here. For example, could there be funny interaction with "single > key" mode with editor on Windows (which I do not use myself but I > think I saw the word in the original report)? Is the configuration > "interactive.singlekey" enabled?
