Unresponsive fetch dialog during remote ref enumeration in GitKraken

Question

Goal
Fetch from a remote repository in GitKraken without blocking the interface while the client enumerates a large number of remote branches or tags.
Constraints and uncertainty
GitKraken’s fetch and clone dialogs do not appear to expose a ref-count limit, pagination, shallow-ref option, or depth-limited refspec for the remote ref advertisement. The exact UI labels, default transport backend, and version-specific defaults may differ across releases, and current error strings or behavior changes have not been independently confirmed.
Because the operation may resolve the full ref list before presenting results, users on remotes with hundreds of refs may experience an unresponsive fetch dialog rather than a partial or paginated result.
Questions

Does GitKraken provide any setting to bound or paginate remote ref enumeration during fetch or clone?
Can a fetch be scoped to a specific refspec or depth to avoid retrieving the complete remote ref advertisement?
Does this behavior depend on the libgit2 or system Git backend, and does it vary by GitKraken version?

Tasadduq Burney · Answer

Resolution
GitKraken does not currently provide a built-in GUI setting to paginate, bound, or limit the number of remote references (branches and tags) enumerated during a fetch or clone operation. Because the client must receive the full remote ref advertisement before the transfer begins, repositories with thousands of refs can cause the fetch dialog to become unresponsive.

Likely Cause and Behavior
GitKraken primarily relies on libgit2 for core operations. In a standard fetch, the client performs a synchronous request to the remote to list all available refs. If the remote repository has an exceptionally high number of tags or branches, the UI thread may hang while waiting for this list to be parsed and processed before the actual data transfer starts.

Workarounds for Large Remotes
Since the GUI does not expose refspec filters or depth limits for the enumeration phase, you must modify the repository configuration via the command line to restrict what GitKraken tracks.

Restrict Refspecs: Modify your .git/config file to fetch only specific branches rather than all remote refs. Replace the default fetch = +refs/heads/*:refs/remotes/origin/* with a specific branch:
git config remote.origin.fetch "+refs/heads/main:refs/remotes/origin/main"

Prune Stale Refs: If the unresponsiveness is caused by a buildup of deleted remote branches that are still tracked locally, run a prune:
git fetch --prune

Verify Backend: Check Preferences > Git to see if you are using the internal libgit2 or System Git. While both must enumerate refs, System Git may handle certain network timeouts or large buffers differently depending on your local Git version.

Verification
To determine if the bottleneck is the GitKraken UI or the remote server's response time, run the following command in the integrated terminal:
git fetch --dry-run
If the terminal hangs at the same point the GUI does, the issue is the volume of remote refs being advertised by the server. If the terminal is fast but the GUI is slow, the bottleneck is in the UI's processing of the ref list.

Diagnostic Detail Needed
Are you using a custom .gitconfig with specific remote.origin.fetch rules, or is the repository using the default "fetch all" configuration?

Unresponsive fetch dialog during remote ref enumeration in GitKraken

Goal

Constraints and uncertainty

Questions

1 answer

Resolution

Likely Cause and Behavior

Workarounds for Large Remotes

Verification

Diagnostic Detail Needed

Your perspective belongs here.

0 question comments