* Git Bug Report: git add --patch > "e" makes keyboard unresponsive
@ 2024-04-24 16:22 Dan Demp
2024-04-24 21:54 ` brian m. carlson
0 siblings, 1 reply; 6+ messages in thread
From: Dan Demp @ 2024-04-24 16:22 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
When doing a git add --patch, I used the "e" option to edit a diff I
couldn't split sufficiently. This worked, however when it moved on to
the next diff, my keyboard became unresponsive.
What did you expect to happen? (Expected behavior)
Not make my keyboard unresponsive.
What happened instead? (Actual behavior)
I was unable to enter any option to proceed with the patch, and even
Ctrl+C failed to kill the git command. I ended up having to close my
Git Bash process and open a new one.
What's different between what you expected and what actually happened?
Keyboard unresponsive.
Anything else you want to add:
I've reproduced this every subsequent time I've tried this, and it's
specific to using the "e" option with --patch.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.42.0.windows.2
cpu: x86_64
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19045
compiler info: gnuc: 13.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
[Enabled Hooks]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive
2024-04-24 16:22 Git Bug Report: git add --patch > "e" makes keyboard unresponsive Dan Demp
@ 2024-04-24 21:54 ` brian m. carlson
2024-04-24 22:23 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: brian m. carlson @ 2024-04-24 21:54 UTC (permalink / raw)
To: Dan Demp; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
On 2024-04-24 at 16:22:12, Dan Demp wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> When doing a git add --patch, I used the "e" option to edit a diff I
> couldn't split sufficiently. This worked, however when it moved on to
> the next diff, my keyboard became unresponsive.
>
> What did you expect to happen? (Expected behavior)
>
> Not make my keyboard unresponsive.
>
> What happened instead? (Actual behavior)
>
> I was unable to enter any option to proceed with the patch, and even
> Ctrl+C failed to kill the git command. I ended up having to close my
> Git Bash process and open a new one.
>
> What's different between what you expected and what actually happened?
>
> Keyboard unresponsive.
>
> Anything else you want to add:
>
> I've reproduced this every subsequent time I've tried this, and it's
> specific to using the "e" option with --patch.
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.
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?
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive
2024-04-24 21:54 ` brian m. carlson
@ 2024-04-24 22:23 ` Junio C Hamano
2024-04-25 4:13 ` Dan Demp
2024-04-25 4:15 ` Dan Demp
0 siblings, 2 replies; 6+ messages in thread
From: Junio C Hamano @ 2024-04-24 22:23 UTC (permalink / raw)
To: brian m. carlson; +Cc: Dan Demp, git
"brian m. carlson" <sandals@crustytoothpaste.net> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive
2024-04-24 22:23 ` Junio C Hamano
@ 2024-04-25 4:13 ` Dan Demp
2024-04-25 4:24 ` Junio C Hamano
2024-04-25 4:15 ` Dan Demp
1 sibling, 1 reply; 6+ messages in thread
From: Dan Demp @ 2024-04-25 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: brian m. carlson, git
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@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive
2024-04-24 22:23 ` Junio C Hamano
2024-04-25 4:13 ` Dan Demp
@ 2024-04-25 4:15 ` Dan Demp
1 sibling, 0 replies; 6+ messages in thread
From: Dan Demp @ 2024-04-25 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: brian m. carlson, git
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive
2024-04-25 4:13 ` Dan Demp
@ 2024-04-25 4:24 ` Junio C Hamano
0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2024-04-25 4:24 UTC (permalink / raw)
To: Dan Demp; +Cc: brian m. carlson, git
Dan Demp <drdemp@gmail.com> writes:
[do not top-post]
>> ... 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?
>
> 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.
Brian's comment was only concentrating on the possibility that an
editor is still open as his first probing effort; I suspected there
was something more than that going on (e.g., after closing the
editor, the control is still stuck), which you just confirmed.
Thanks for confirming my suspicion.
After this point, it is beyond what I know about the platform, and
I'll leave it to "Git for Windows" folks to take further look.
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-25 4:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-24 16:22 Git Bug Report: git add --patch > "e" makes keyboard unresponsive Dan Demp
2024-04-24 21:54 ` brian m. carlson
2024-04-24 22:23 ` Junio C Hamano
2024-04-25 4:13 ` Dan Demp
2024-04-25 4:24 ` Junio C Hamano
2024-04-25 4:15 ` Dan Demp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).