Open JeroenBos opened 1 year ago
@JeroenBos thanks for the issue! Could you upload the log file from GitHub Desktop so that I could see if that shows anything interesting? To access the log files go to the file menu in GitHub Desktop and select Help
> Show Logs
. The log files are created daily -- please upload a log file as an attachment from a day where you experienced the issue.
I edited my post and added minimal logs. As a description of what I did: I did the squash operation twice:
#!/bin/sh
, which was pretty much instantaneous#!/bin/bash
, which has the 30 second timeout (even with empty ~/.bashrc
)I see that the logs are about ssh, so I'll add some related information:
I rebuilt an older version (3.2.0) from source, as I'm certain I didn't have the above behavior yet in that timeframe. I could still observe it with that version, so I concluce it has nothing to do with GitHub Desktop, and I'll have to look elsewhere for this puzzling behavior. Sorry for the inconvenience.
Well, I am starting to think it is related to GitHub desktop.
A git commit
command from shell works fine, no idling. A commit from GitHub Desktop idles, and I've figured out that it is related to WSL2.
Somehow the bash
vs sh
difference triggers WSL in GitHub desktop, but not in regular git usage.
I found out by disabling hyperv in BIOS, after which committing in GitHub desktop gave me the following error:
2023-05-16T10:46:54.318Z - error: [ui] `git commit -F -` exited with an unexpected code: 1.
stderr:
WSL2 is not supported with your current machine configuration.
Please enable the "Virtual Machine Platform" optional component and ensure virtualization is enabled in the BIOS.
For information please visit https://aka.ms/enablevirtualization
Error code: Bash/Service/CreateInstance/CreateVm/0x80370102
After uninstalling WSL (properly, as in including unticking the “Windows Subsystem for Linux” option in the Windows Features dialog box), this issue was resolved.
Now, I don't use WSL for anything. Admittedly I had installed it to try something, and ever since I've been having this issue with GitHub Desktop, but I didn't think of it. Merely installing WSL2 shouldn't affect GitHub Desktop imho.
What I think is going on:
git -c credential.helper= fetch --progress --prune --recurse-submodules=on-demand origin
That hangs. Possibly that trying to execute something in WSL hangs (because it isn't running on my system), or maybe it is started and then it hangs on the message Enter passphrase for ~/.ssh/id_rsa:
as WSL for sure can't find the ssh-agent
(which is running on the Windows side). Either could explain the the 30s wait. The problem is that it shouldn't be using WSL for anything in the first place.
The problem
Since 3.2.2 or 3.2.3 I observe a regression, namely that squashing commits, or in general rebasing, takes very long in the presence of a
post-checkout
bash script hook. There is some sort of timeout going on where you have to wait for pretty much exactly 30 seconds.Release version
3.2.3 (x64)
Operating system
Windows 10
Steps to reproduce the behavior
./.git/hooks/post-checkout
with the contents#!/bin/bash
(nothing else)Observe that the "Squash in progress" dialog takes 30 seconds.
Log files
Screenshots
No response
Additional context
The timeout does not occur when
#!/bin/bash
(but e.g. with#!/bin/sh
)EDIT: I have it with normal commits too, not just rebases.