Bug: The 5th operation with GitLab hangs indefinitely

[Reyhn3]

This is the root cause for why I first created #1598.

SourceGit stops working with GitLab. It has been a problem all year long, and it is highly repeatable, but I'm at a loss of how to properly troubleshoot it. These are my observations:

• It affects only GitLab. Azure Devops and GitHub repos do not appear to cause this issue.
• I get exactly four working operations (pull, push, fetch) before this problem happens. Consistently, on the fifth operation, any operation just hangs for a long time.
• The four successful operations can be on any GitLab-repo, i.e. all four operations on the same repo, or one operation each on four repos, or two operations on the same repo and the rest on other repos etc.
• The behavior is repeatable for any GitLab repo(s).
• No other operation with the initial GitLab repo works until SourceGit has been restarted. The operation dialog is not cancellable (hence Bug / Feature Request: Cancel operation #1598).
• If I kill the SourceGit process and start the application again, GitLab works again.
• Azure DevOps and GitHub operations work fine at the same time as a GitLab-repo is frozen.
• Doing git operations on other GitLab-repos using SourceGit work fine at the same time as the operation is hung for the initial repo.
• Doing git operations in the terminal for the same repo and for other GitLab-repos work fine at the same time as SourceGit is hung.

I'm on Linux, using SourceGit 2025.39.
System:
Kernel: 6.17.9-300.fc43.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
Desktop: KDE Plasma v: 6.5.3 Distro: Fedora Linux 43 (Forty Three)

[love-linger]

It seems like an authorization issue (token expired?) because after git process started, SourceGit does not control it but only shows the output of this process.

I do not know how to deal with it. And the cancel operation you have mentioned is hard to implement on Unix-like system (Linux and macOS). Since the git sub-process will also spawn its child process, We have tried many ways to kill the whole git sub-process tree, none of it works on Linux and macOS. See PR #1012

[Reyhn3]

I doubt it is an authorization issue (because I don't have any PATs on GitLab), but I don't know how to rule this out. Except for that git and other git GUIs work on the same repositories at the same time as SourceGit is having issues.

Is there any way to turn on debug logging to see what happens with the git process?

[Reyhn3]

Some of the times I get these errors:

[love-linger]

All the error messages come from git process (the second is from ssh process which is spawn by the git process). And they all show that there is something error with your network connection.

Do you have a network proxy or VPN?

[love-linger]

When SourceGit creates a git subprocess, it sets the following environment variables.

• SSH_ASKPASS - A path string points to SourceGit executable. Force git to use SourceGit as plain-text-based ask-pass tool
• SSH_ASKPASS_REQUIRE - Always prefer. Tell git to use GUI based (SourceGit itself) tool for passphrase
• DISPLAY - Only used on Linux. required. Same as SSH_ASKPASS_REQUIRE.
• GIT_SSH_COMMAND - If you have provided a private SSH key, this variable will be ssh -i '<path_to_key>'
• LANG and LC_ALL - Always C. For old versions of git-credential-manager, it only supports English.

SourceGit will use -c credential.helper=manager to force using git-credential-manager as an authorization tool.

And some of your env settings (such as ~/.zsh_profile which is only used by zsh shell) will not work with SourceGit.

Other than the above, I don't know what differences there are between the way SourceGit creates git subprocesses and other git clients.

[Reyhn3]

I am closing this bug, because as @love-linger says, it is most likely not a bug in SourceGit itself.

I can still reproduce the problem consistently, but I have from time to time noticed that it also affects git-operations outside of SourceGit. That hints that it is something else on my system that is causing it. The most strange thing, though, is that quitting SoureGit seems to fix it...

For my own sake, I'll continue troubleshooting, and if I find anything relevant to contribute with, I'll add it here.