Short answer
For repositories on a local drive, GitKraken behaves as an event-driven client rather than a fixed-interval poller: a CLI git commit or git checkout that moves HEAD is normally reflected in the commit graph within roughly a second on a local SSD, without any user action. The likely mechanism is a filesystem watch on the .git directory — a CLI commit writes exactly the paths such a watcher would monitor (HEAD, refs/, packed-refs, the index, and reflogs). Treat the watcher detail as the probable explanation rather than a published specification: the watch scope and any debounce are version- and OS-specific, so confirm against the release notes for your installed GitKraken version.
Confirmed behavior versus inferred mechanism
- Confirmed: GitKraken refreshes after its own operations and when the application window regains focus. Auto-fetch is a separate, user-configured timer for pulling remote refs; it does not govern detection of local CLI commits, so changing it will not change CLI-to-graph latency.
- Confirmed: GitKraken reads repositories through its own bundled Git tooling rather than relying on your CLI binary for core reads, so your installed
git version does not materially affect refresh speed. Version alignment matters mainly for write-path compatibility such as index formats, not latency.
- Probable: OS-level file events on
.git drive external-change detection. This fits the observed behavior and explains why latency scales with repository size — detection itself is fast, while graph layout and rendering of long histories dominate the visible delay.
When updates appear only after clicking around
If the graph refreshes only when you refocus or interact with the window, filesystem events are being missed or suppressed. The usual culprits are repositories on network shares, NFS, or WSL-mounted paths, where file-event delivery is unreliable, and exhausted inotify watch limits on Linux. In that fallback mode, effective latency equals time-to-refocus rather than any fixed interval.
A two-minute verification on your setup
- In a scratch repository open in GitKraken, run
git commit --allow-empty -m "watcher test" from a terminal while the GitKraken window is unfocused, and note how long until the graph updates. Repeat with the window focused to separate watcher-driven from focus-driven refresh.
- Repeat on a large-history clone to see how much of the delay is rendering rather than detection.
- On Linux, check watch headroom with
cat /proc/sys/fs/inotify/max_user_watches; if it is low relative to your repository size, raising it may restore event-driven refresh.
One detail that changes the recommendation
Is the repository on a local drive, or on a network share or WSL mount? On a local drive, the behavior above should hold, and slow refresh in very large repositories is mostly layout cost. On a network or WSL path, assume events may never arrive reliably; the practical options are keeping the working copy on local storage or accepting focus and manual refresh as your triggers. One related caution: running CLI writes while GitKraken holds the index can produce index.lock conflicts — wait for the in-progress GUI operation to finish instead of retrying the CLI command.
gitkraken