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

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]

On 2024-04-24 at 16:22:12, Dan Demp wrote:

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" <sandals@crustytoothpaste.net> writes:

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

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

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:

Dan Demp <drdemp@gmail.com> writes:

[do not top-post]

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.

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.

Hi Dan,

On Wed, 24 Apr 2024, Dan Demp wrote:

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

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

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?

Hi Junio,

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

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

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

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 ;-)

Hi Junio,

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

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.

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

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

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

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.