{"thread":{"id":"61359","subject":"Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","startedAt":"2024-04-24T16:22:24Z","lastAt":"2025-03-26T07:53:54Z","messageCount":12,"participants":["Dan Demp","brian m. carlson","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"493416","messageId":"CADs5QabwDtUpehNY3hr6BzKyfpp-Ts54TANGkygWPcN3T=OSOg@mail.gmail.com","threadId":"61359","inReplyTo":null,"subject":"Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Dan Demp","fromEmail":"drdemp@gmail.com","sentAt":"2024-04-24T16:22:12Z","receivedAt":"2024-04-24T16:22:24Z","isPatch":false,"sender":{"key":"drdemp@gmail.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nWhen doing a git add --patch, I used the \"e\" option to edit a diff I\ncouldn't split sufficiently. This worked, however when it moved on to\nthe next diff, my keyboard became unresponsive.\n\nWhat did you expect to happen? (Expected behavior)\n\nNot make my keyboard unresponsive.\n\nWhat happened instead? (Actual behavior)\n\nI was unable to enter any option to proceed with the patch, and even\nCtrl+C failed to kill the git command. I ended up having to close my\nGit Bash process and open a new one.\n\nWhat's different between what you expected and what actually happened?\n\nKeyboard unresponsive.\n\nAnything else you want to add:\n\nI've reproduced this every subsequent time I've tried this, and it's\nspecific to using the \"e\" option with --patch.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.42.0.windows.2\ncpu: x86_64\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Windows 10.0 19045\ncompiler info: gnuc: 13.2\nlibc info: no libc information available\n$SHELL (typically, interactive shell): C:\\Program Files\\Git\\usr\\bin\\bash.exe\n\n\n[Enabled Hooks]\n"},{"id":"493446","messageId":"Zil_m_1B0wcLejNH@tapette.crustytoothpaste.net","threadId":"61359","inReplyTo":"CADs5QabwDtUpehNY3hr6BzKyfpp-Ts54TANGkygWPcN3T=OSOg@mail.gmail.com","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-04-24T21:54:35Z","receivedAt":"2024-04-24T22:04:36Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-04-24 at 16:22:12, Dan Demp wrote:\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> When doing a git add --patch, I used the \"e\" option to edit a diff I\n> couldn't split sufficiently. This worked, however when it moved on to\n> the next diff, my keyboard became unresponsive.\n> \n> What did you expect to happen? (Expected behavior)\n> \n> Not make my keyboard unresponsive.\n> \n> What happened instead? (Actual behavior)\n> \n> I was unable to enter any option to proceed with the patch, and even\n> Ctrl+C failed to kill the git command. I ended up having to close my\n> Git Bash process and open a new one.\n> \n> What's different between what you expected and what actually happened?\n> \n> Keyboard unresponsive.\n> \n> Anything else you want to add:\n> \n> I've reproduced this every subsequent time I've tried this, and it's\n> specific to using the \"e\" option with --patch.\n\nUsing the \"e\" option should invoke your editor and wait until it exits.\nThe only way Git has to know that you're done editing is that the editor\nprocess it invokes has exited.\n\nWhat does \"git var GIT_EDITOR\" at a Git Bash prompt print? If you have\nyour editor configured to open in an existing editor window, does\nclosing the new editor tab or window that Git causes to be opened fix\nthe problem?\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"493449","messageId":"xmqqedauwgbk.fsf@gitster.g","threadId":"61359","inReplyTo":"Zil_m_1B0wcLejNH@tapette.crustytoothpaste.net","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-04-24T22:23:27Z","receivedAt":"2024-04-24T22:23:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> Using the \"e\" option should invoke your editor and wait until it exits.\n> The only way Git has to know that you're done editing is that the editor\n> process it invokes has exited.\n\nWhichever editor was launched, unless the user explicitly said the hint\nis not necessary by setting advice.waitingForEditor to false, the code\nshould have given something like this:\n\n hint: Waiting for your editor to close the file...\n\nso ...\n\n> What does \"git var GIT_EDITOR\" at a Git Bash prompt print? If you have\n> your editor configured to open in an existing editor window, does\n> closing the new editor tab or window that Git causes to be opened fix\n> the problem?\n\n... I would expect that there may be something more than a silly\n\"the editor is running elsewhere and the user is stuck, expecting\nsomething to happen but the editor is waiting for the user\" problem\nhere. For example, could there be funny interaction with \"single\nkey\" mode with editor on Windows (which I do not use myself but I\nthink I saw the word in the original report)? Is the configuration\n\"interactive.singlekey\" enabled?\n"},{"id":"493456","messageId":"CADs5QaY=dJ=MXNYgqyEQA9xmcBkeocZh5z9Tq_iNfnFgCHR_=w@mail.gmail.com","threadId":"61359","inReplyTo":"xmqqedauwgbk.fsf@gitster.g","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Dan Demp","fromEmail":"drdemp@gmail.com","sentAt":"2024-04-25T04:13:03Z","receivedAt":"2024-04-25T04:13:16Z","isPatch":false,"sender":{"key":"drdemp@gmail.com","avatar":null},"body":"To be clear, I did close the editor, at which point Git Bash shows me\nthe next diff and asks me to choose an option (y, n, a, d, ...). It's\nat that point the keyboard is unresponsive. Not while the editor is\nstill open.\n\nIf it matters, I'm using Notepad++ as the editor.\n\nOn Wed, Apr 24, 2024 at 5:23 PM Junio C Hamano wrote:\n>\n> \"brian m. carlson\" writes:\n>\n> > Using the \"e\" option should invoke your editor and wait until it exits.\n> > The only way Git has to know that you're done editing is that the editor\n> > process it invokes has exited.\n>\n> Whichever editor was launched, unless the user explicitly said the hint\n> is not necessary by setting advice.waitingForEditor to false, the code\n> should have given something like this:\n>\n> hint: Waiting for your editor to close the file...\n>\n> so ...\n>\n> > What does \"git var GIT_EDITOR\" at a Git Bash prompt print? If you have\n> > your editor configured to open in an existing editor window, does\n> > closing the new editor tab or window that Git causes to be opened fix\n> > the problem?\n>\n> ... I would expect that there may be something more than a silly\n> \"the editor is running elsewhere and the user is stuck, expecting\n> something to happen but the editor is waiting for the user\" problem\n> here. For example, could there be funny interaction with \"single\n> key\" mode with editor on Windows (which I do not use myself but I\n> think I saw the word in the original report)? Is the configuration\n> \"interactive.singlekey\" enabled?\n"},{"id":"493457","messageId":"CADs5QabuZYN9AbhZd6gjwtvuamietz0RToBFcmbxeFV1v7U2KA@mail.gmail.com","threadId":"61359","inReplyTo":"xmqqedauwgbk.fsf@gitster.g","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Dan Demp","fromEmail":"drdemp@gmail.com","sentAt":"2024-04-25T04:15:53Z","receivedAt":"2024-04-25T04:16:05Z","isPatch":false,"sender":{"key":"drdemp@gmail.com","avatar":null},"body":"To be clear, I did close the editor, at which point Git Bash shows me\nthe next diff and asks me to choose an option (y, n, a, d, ...). It's\nat that point the keyboard is unresponsive. Not while the editor is\nstill open.\n\nIf it matters, I'm using Notepad++ as the editor.\n"},{"id":"493458","messageId":"xmqqo79yhxxb.fsf@gitster.g","threadId":"61359","inReplyTo":"CADs5QaY=dJ=MXNYgqyEQA9xmcBkeocZh5z9Tq_iNfnFgCHR_=w@mail.gmail.com","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-04-25T04:24:32Z","receivedAt":"2024-04-25T04:24:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dan Demp writes:\n\n[do not top-post]\n\n>> ... I would expect that there may be something more than a silly\n>> \"the editor is running elsewhere and the user is stuck, expecting\n>> something to happen but the editor is waiting for the user\" problem\n>> here. For example, could there be funny interaction with \"single\n>> key\" mode with editor on Windows (which I do not use myself but I\n>> think I saw the word in the original report)? Is the configuration\n>> \"interactive.singlekey\" enabled?\n>\n> To be clear, I did close the editor, at which point Git Bash shows me\n> the next diff and asks me to choose an option (y, n, a, d, ...). It's\n> at that point the keyboard is unresponsive. Not while the editor is\n> still open.\n\nBrian's comment was only concentrating on the possibility that an\neditor is still open as his first probing effort; I suspected there\nwas something more than that going on (e.g., after closing the\neditor, the control is still stuck), which you just confirmed.\n\nThanks for confirming my suspicion.\n\nAfter this point, it is beyond what I know about the platform, and\nI'll leave it to \"Git for Windows\" folks to take further look.\n\nThanks.\n"},{"id":"514372","messageId":"84c3ccdb-2aaf-9b34-91c5-cf5c27f53dcb@gmx.de","threadId":"61359","inReplyTo":"CADs5QabwDtUpehNY3hr6BzKyfpp-Ts54TANGkygWPcN3T=OSOg@mail.gmail.com","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-03-16T03:34:36Z","receivedAt":"2025-03-16T03:34:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Dan,\n\nOn Wed, 24 Apr 2024, Dan Demp wrote:\n\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n>\n> When doing a git add --patch, I used the \"e\" option to edit a diff I\n> couldn't split sufficiently. This worked, however when it moved on to\n> the next diff, my keyboard became unresponsive.\n\nIt is likely that this is related to\nhttps://github.com/git-for-windows/git/issues/4776 (but I can't be sure\nbecause your bug report did not mention overriding the editor), and will\nbe fixed in Git for Windows v2.49.0.\n\nI refused to release on a Friday (absent any good reason) which is why\nthis version is scheduled to appear this coming Monday.\n\nCiao,\nJohannes\n\n>\n> What did you expect to happen? (Expected behavior)\n>\n> Not make my keyboard unresponsive.\n>\n> What happened instead? (Actual behavior)\n>\n> I was unable to enter any option to proceed with the patch, and even\n> Ctrl+C failed to kill the git command. I ended up having to close my\n> Git Bash process and open a new one.\n>\n> What's different between what you expected and what actually happened?\n>\n> Keyboard unresponsive.\n>\n> Anything else you want to add:\n>\n> I've reproduced this every subsequent time I've tried this, and it's\n> specific to using the \"e\" option with --patch.\n>\n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n>\n>\n> [System Info]\n> git version:\n> git version 2.42.0.windows.2\n> cpu: x86_64\n> sizeof-long: 4\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> feature: fsmonitor--daemon\n> uname: Windows 10.0 19045\n> compiler info: gnuc: 13.2\n> libc info: no libc information available\n> $SHELL (typically, interactive shell): C:\\Program Files\\Git\\usr\\bin\\bash.exe\n>\n>\n> [Enabled Hooks]\n>\n>\n"},{"id":"514444","messageId":"xmqqsenb70u0.fsf@gitster.g","threadId":"61359","inReplyTo":"84c3ccdb-2aaf-9b34-91c5-cf5c27f53dcb@gmx.de","subject":"Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-17T22:24:07Z","receivedAt":"2025-03-17T22:24:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I refused to release on a Friday (absent any good reason) which is why\n> this version is scheduled to appear this coming Monday.\n\nNot on-topic for any particular bug, but do you want to probably\ncoordinate on what day of the week a release is made, perhaps? I've\nbeen trying to stick to the same time-of-the-day we established\nearlier for embargoed coordinated releases, which is 1700 UTC - 2600\nAsia/Tokyo. But the choice of the day-of-the-week has been more or\nless arbitrary picked by me to happen on Fridays for the past few\nreleases; it seems 2.47 was done on Monday.\n\nAny preferences?\n"},{"id":"514990","messageId":"2dd6e0fa-b997-f69c-874b-f424325123a8@gmx.de","threadId":"61359","inReplyTo":"xmqqsenb70u0.fsf@gitster.g","subject":"Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-03-25T11:23:58Z","receivedAt":"2025-03-25T11:24:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 17 Mar 2025, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n> > I refused to release on a Friday (absent any good reason) which is why\n> > this version is scheduled to appear this coming Monday.\n>\n> Not on-topic for any particular bug, but do you want to probably\n> coordinate on what day of the week a release is made, perhaps? I've\n> been trying to stick to the same time-of-the-day we established\n> earlier for embargoed coordinated releases, which is 1700 UTC - 2600\n> Asia/Tokyo. But the choice of the day-of-the-week has been more or\n> less arbitrary picked by me to happen on Fridays for the past few\n> releases; it seems 2.47 was done on Monday.\n>\n> Any preferences?\n\nI have stated my preferences previously, even attempted to coordinate\nbetween Git and Git for Windows, and I observe that the way I present\narguments is ineffective. Therefore I will try something new: Refer you to\na couple of resources that could elicit some introspection and\n(re-)thinking of existing practices:\n\n- https://daniel.haxx.se/blog/2022/08/16/the-curl-release-cycle/\n\n- https://www.researchgate.net/publication/268815678_Why_and_How_Should_Open_Source_Projects_Adopt_Time-Based_Releases\n (old, still relevant)\n\n- Notice the weekday when Firefox releases new versions:\n https://www.mozilla.org/en-US/firefox/releases/\n\n- https://msrc.microsoft.com/blog/2023/11/reflecting-on-20-years-of-patch-tuesday/\n\n- https://www.linkedin.com/pulse/best-day-week-release-software-rajith-muditha-attapattu-wvpuc\n\n- https://corner.buka.sh/why-dont-deploy-on-friday-is-more-than-just-a-superstition/\n (yes, new Git releases can elicit support escalations on weekends)\n\n- https://www.wingravity.com/blog/deploying-on-a-friday-to-risk-or-not-to-risk\n\n- https://www.sinergiapositiva.com/2024/11/19/friday-deployments-arent-the-issue-your-quality-processes-are/\n\nCiao,\nJohannes\n"},{"id":"514991","messageId":"xmqqsen1mj1y.fsf@gitster.g","threadId":"61359","inReplyTo":"2dd6e0fa-b997-f69c-874b-f424325123a8@gmx.de","subject":"Re: Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-25T11:44:09Z","receivedAt":"2025-03-25T11:44:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I have stated my preferences previously, even attempted to coordinate\n> between Git and Git for Windows, and I observe that the way I present\n> arguments is ineffective. Therefore I will try something new: Refer you to\n> a couple of resources that could elicit some introspection and\n> (re-)thinking of existing practices:\n\nIt is even less effective. Friday may be bad and many people may\nagree to avoid Friday releases. So what is your preference?\n\nIn any case, I'll go back to my vacation ;-)\n"},{"id":"515075","messageId":"c4753c0d-d957-c4d0-a452-1e592cade34f@gmx.de","threadId":"61359","inReplyTo":"xmqqsen1mj1y.fsf@gitster.g","subject":"Re: Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-03-26T07:02:22Z","receivedAt":"2025-03-26T07:02:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 25 Mar 2025, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n> > I have stated my preferences previously, even attempted to coordinate\n> > between Git and Git for Windows, and I observe that the way I present\n> > arguments is ineffective. Therefore I will try something new: Refer you to\n> > a couple of resources that could elicit some introspection and\n> > (re-)thinking of existing practices:\n>\n> It is even less effective. Friday may be bad and many people may\n> agree to avoid Friday releases.\n\nThank you for your honesty. I want to share that I have spent considerable\ntime reflecting on the release process because I genuinely care about\nimproving it both for the sake of Git's users as well as its contributors.\nI've thoughtfully weighed the challenges -- like having clear and\ndependable timelines, like timing releases around holidays, weekends, and\naccommodating embargoed releases -- and observe significant room for\nimprovement.\n\nI approached writing the email to which you replied with the intention of\nfostering a collaborative discussion. I put a lot of effort into crafting\nmy thoughts constructively, writing and rewriting the email, even deleting\nseveral well-laid out arguments in the interest of a less confrontational\nand dismissive tone in favor of inspiring reflection, and I had hoped for\na response that mirrored that level of consideration.\n\nThat said, I am eager to hear your thoughts on how we can shift this\ndialogue into a more productive and collaborative direction, one where we\nfocus on enhancing the project together.\n\n> So what is your preference?\n\nApart from seeing the need to improve on the status quo, I have no fixed\npreference. How do _you_ envision a release process that could better\nserve the needs of everyone involved?\n\nLooking forward to hearing your insights,\nJohannes\n\n> In any case, I'll go back to my vacation ;-)\n\nI hope it was a good, relaxing one, that helped you un- and rewind.\n"},{"id":"515085","messageId":"xmqqy0wsi5ww.fsf@gitster.g","threadId":"61359","inReplyTo":"c4753c0d-d957-c4d0-a452-1e592cade34f@gmx.de","subject":"Re: Releasing versions on Fridays, was Re: Git Bug Report: git add --patch > \"e\" makes keyboard unresponsive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-26T07:53:51Z","receivedAt":"2025-03-26T07:53:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> That said, I am eager to hear your thoughts on how we can shift this\n> dialogue into a more productive and collaborative direction, one where we\n> focus on enhancing the project together.\n\nI am easy and can release on any day of the week.\n\nYou are the one with a stricter preference.\n\nSo, you can just say something like \"let's make it at 1700 UTC on\nMonday\" and I can respond with \"OK, let's make it so\".\n\nLet's not make it more complicated than it needs to be.\n"}]}