Git Bug Report: git add --patch > "e" makes keyboard unresponsive

Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Dan Demp]

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]

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[brian m. carlson]

[-- 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 --]

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Junio C Hamano]

"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?

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Dan Demp]

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?

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Junio C Hamano]

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.

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Dan Demp]

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.

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Johannes Schindelin]

Hi Dan,

On Wed, 24 Apr 2024, 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.

It is likely that this is related to
https://github.com/git-for-windows/git/issues/4776 (but I can't be sure
because your bug report did not mention overriding the editor), and will
be fixed in Git for Windows v2.49.0.

I refused to release on a Friday (absent any good reason) which is why
this version is scheduled to appear this coming Monday.

Ciao,
Johannes

>
> 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]
>
>

Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I refused to release on a Friday (absent any good reason) which is why
> this version is scheduled to appear this coming Monday.

Not on-topic for any particular bug, but do you want to probably
coordinate on what day of the week a release is made, perhaps?  I've
been trying to stick to the same time-of-the-day we established
earlier for embargoed coordinated releases, which is 1700 UTC - 2600
Asia/Tokyo.  But the choice of the day-of-the-week has been more or
less arbitrary picked by me to happen on Fridays for the past few
releases; it seems 2.47 was done on Monday.

Any preferences?

Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Johannes Schindelin]

Hi Junio,

On Mon, 17 Mar 2025, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I refused to release on a Friday (absent any good reason) which is why
> > this version is scheduled to appear this coming Monday.
>
> Not on-topic for any particular bug, but do you want to probably
> coordinate on what day of the week a release is made, perhaps?  I've
> been trying to stick to the same time-of-the-day we established
> earlier for embargoed coordinated releases, which is 1700 UTC - 2600
> Asia/Tokyo.  But the choice of the day-of-the-week has been more or
> less arbitrary picked by me to happen on Fridays for the past few
> releases; it seems 2.47 was done on Monday.
>
> Any preferences?

I have stated my preferences previously, even attempted to coordinate
between Git and Git for Windows, and I observe that the way I present
arguments is ineffective. Therefore I will try something new: Refer you to
a couple of resources that could elicit some introspection and
(re-)thinking of existing practices:

- https://daniel.haxx.se/blog/2022/08/16/the-curl-release-cycle/

- https://www.researchgate.net/publication/268815678_Why_and_How_Should_Open_Source_Projects_Adopt_Time-Based_Releases
  (old, still relevant)

- Notice the weekday when Firefox releases new versions:
  https://www.mozilla.org/en-US/firefox/releases/

- https://msrc.microsoft.com/blog/2023/11/reflecting-on-20-years-of-patch-tuesday/

- https://www.linkedin.com/pulse/best-day-week-release-software-rajith-muditha-attapattu-wvpuc

- https://corner.buka.sh/why-dont-deploy-on-friday-is-more-than-just-a-superstition/
  (yes, new Git releases can elicit support escalations on weekends)

- https://www.wingravity.com/blog/deploying-on-a-friday-to-risk-or-not-to-risk

- https://www.sinergiapositiva.com/2024/11/19/friday-deployments-arent-the-issue-your-quality-processes-are/

Ciao,
Johannes

Re: Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I have stated my preferences previously, even attempted to coordinate
> between Git and Git for Windows, and I observe that the way I present
> arguments is ineffective. Therefore I will try something new: Refer you to
> a couple of resources that could elicit some introspection and
> (re-)thinking of existing practices:

It is even less effective.  Friday may be bad and many people may
agree to avoid Friday releases.  So what is your preference?

In any case, I'll go back to my vacation ;-)

Re: Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Johannes Schindelin]

Hi Junio,

On Tue, 25 Mar 2025, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I have stated my preferences previously, even attempted to coordinate
> > between Git and Git for Windows, and I observe that the way I present
> > arguments is ineffective. Therefore I will try something new: Refer you to
> > a couple of resources that could elicit some introspection and
> > (re-)thinking of existing practices:
>
> It is even less effective.  Friday may be bad and many people may
> agree to avoid Friday releases.

Thank you for your honesty. I want to share that I have spent considerable
time reflecting on the release process because I genuinely care about
improving it both for the sake of Git's users as well as its contributors.
I've thoughtfully weighed the challenges -- like having clear and
dependable timelines, like timing releases around holidays, weekends, and
accommodating embargoed releases -- and observe significant room for
improvement.

I approached writing the email to which you replied with the intention of
fostering a collaborative discussion. I put a lot of effort into crafting
my thoughts constructively, writing and rewriting the email, even deleting
several well-laid out arguments in the interest of a less confrontational
and dismissive tone in favor of inspiring reflection, and I had hoped for
a response that mirrored that level of consideration.

That said, I am eager to hear your thoughts on how we can shift this
dialogue into a more productive and collaborative direction, one where we
focus on enhancing the project together.

> So what is your preference?

Apart from seeing the need to improve on the status quo, I have no fixed
preference. How do _you_ envision a release process that could better
serve the needs of everyone involved?

Looking forward to hearing your insights,
Johannes

> In any case, I'll go back to my vacation ;-)

I hope it was a good, relaxing one, that helped you un- and rewind.

Re: Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > "e" makes keyboard unresponsive

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> That said, I am eager to hear your thoughts on how we can shift this
> dialogue into a more productive and collaborative direction, one where we
> focus on enhancing the project together.

I am easy and can release on any day of the week.

You are the one with a stricter preference.

So, you can just say something like "let's make it at 1700 UTC on
Monday" and I can respond with "OK, let's make it so".

Let's not make it more complicated than it needs to be.