GitKraken Desktop ↔ External Git Changes: Should a Filesystem Watcher Auto‑Refresh the Cache?

Answer

Yes—GitKraken Desktop should offer a background file‑system watcher that invalidates the SQLite cache when relevant changes occur. The feature should be opt‑in by default and throttled to avoid performance spikes in large repositories.

Why this matters

• External edits (e.g., from a terminal or another editor) can leave the UI out of sync, confusing users about the true status of their working tree.
• Automatic invalidation eliminates stale status displays and aligns the UI with the repository’s actual state.
• Without a watcher, users must manually refresh or restart the app, which is inconvenient for real‑time workflows.

Trade‑offs

• Consistency vs. Performance: Rebuilding the SQLite index on every change can be expensive for repos with thousands of files. A debounce or batch window (e.g., 500 ms) mitigates this.
• False positives: Background processes may trigger events that are unrelated to the working tree. Filtering by the repository root and only reacting to file‑create, modify, or delete events keeps the refresh accurate.
• User predictability: Automatic refreshes can surprise users if they rely on a stable view. Making the feature opt‑in preserves control.

Recommended Implementation Path

1. Add a toggle in the Settings panel: Detect external file changes (default: off).
2. When enabled, start a platform‑specific watcher (inotify on Linux, FSEvents on macOS, ReadDirectoryChangesW on Windows) that listens to the repository root.
3. On a relevant event, debounce the refresh by 500 ms to coalesce rapid changes.
4. Invalidate the cache only if the event path falls under the working tree (exclude .git, node_modules, etc.).
5. Re‑build the SQLite index asynchronously and trigger a UI refresh once complete.
6. Provide a status indicator in the UI (e.g., a subtle “Syncing…” spinner) so users know a refresh is in progress.

Verification Checklist

• Enable the setting, modify a tracked file from a terminal, and confirm the UI updates within 500 ms.
• Benchmark rebuild time on a repo >10,000 files; compare manual vs. automatic mode.
• Inspect debug logs to ensure only relevant events trigger a rebuild.

Missing Diagnostic Detail

To fine‑tune the debounce window and decide whether to enable the feature by default, we need to know the typical repository size in your workflow. If your repos regularly exceed 20,000 files, a longer debounce (e.g., 1 s) may be safer.