Diagnosing Slow Sourcetree Performance in Large Git Repositories

Recognizable condition

Sourcetree becomes unresponsive or shows delays longer than 10 seconds when fetching, pulling, or displaying commit history in repositories that are roughly >1 GB or contain >100 k commits. The UI may freeze, progress bars stall, and CPU or disk usage spikes while the operation is in progress.

Cause / diagnostic table

Possible cause	Observable symptom
Built‑in merge conflict visualizer enabled	High CPU usage during diff/view operations; UI lag when opening a file with conflicts
File status monitoring for thousands of files	Continuous disk I/O; slow refresh of the file list view
Large LFS pointer resolution (auto‑fetch)	Network stall or high bandwidth usage when pulling; progress bar stuck on LFS download
Git garbage collection disabled or overdue	Increased repository size on disk; slower object lookups; occasional GC pauses during fetch

Ordered checks

1. Monitor resource usage
   • Where: OS task manager (Windows Task Manager, macOS Activity Monitor, or Linux top/htop).
   • Permissions: Standard user account; no admin needed.
   • Steps: Reproduce the lag (e.g., click Fetch on a remote branch). Observe CPU, memory, and disk I/O.
   • Expected check: If CPU > 70 % or disk I/O stays high for the duration of the lag, note which resource is dominant.
   • Risk: None; observation only.
2. Disable the merge conflict visualizer
   • Where: Sourcetree → Tools → Options (Windows) or Preferences (macOS) → Diff tab.
   • Permissions: Ability to change Sourcetree preferences (standard user).
   • Steps: Uncheck Enable merge conflict visualizer, click OK, restart Sourcetree, then repeat the operation that caused lag.
   • Expected check: UI responsiveness improves (delay drops below ~2 seconds) and CPU usage falls.
   • Risk: You will not see visual conflict markers until you re‑enable the option.
3. Turn off file status icons
   • Where: Same preferences pane → File Status tab.
   • Permissions: Standard user.
   • Steps: Uncheck Show file status icons, apply, restart Sourcetree, test again.
   • Expected check: File list refreshes faster; disk I/O reduces.
   • Risk: You lose visual indication of modified/added/deleted files in the working tree.
4. Temporarily disable LFS auto‑fetch
   • Where: Sourcetree → Tools → Options → Git → LFS tab.
   • Permissions: Standard user.
   • Steps: Uncheck Automatically fetch LFS files, apply, restart, then run a fetch/pull.
   • Expected check: Pull completes quickly if LFS objects were the bottleneck; LFS objects remain on the remote.
   • Risk: Working copy will lack the actual large binary files until you manually fetch them (git lfs pull).
5. Run garbage collection from the command line
   • Where: Terminal / Command Prompt inside the repository root.
   • Permissions: Read/write access to the repository; ensure you are not on a shared branch unless you have a backup.
   • Steps: git gc --aggressive --prune=now
   • Expected check: Repository size on disk reduces; subsequent Sourcetree operations are faster.
   • Risk: --aggressive can rewrite object IDs and break shallow clones or other clients that rely on the exact object database. Always back up (cp -R repo repo.backup) or work on a disposable clone before running.
6. Test with a shallow clone
   • Where: Any directory where you can create a test clone.
   • Permissions: Standard user.
   • Steps: git clone --depth 1 shallow-test
   • Expected check: Operations (fetch, log) in the shallow clone are fast; if they remain slow, the issue is likely not history size.
   • Risk: None; the shallow clone is disposable.

Fixes tied to findings

• If disabling the merge conflict visualizer or file status icons restores responsiveness, keep those options off for large repositories or enable them only on specific branches where you need conflict visualization.
• If LFS auto‑fetch was the cause, enable LFS lazy loading (git lfs fetch --recent) or configure Sourcetree to fetch LFS objects only on demand (Tools → Options → Git → LFS → Fetch LFS files only when needed).
• If garbage collection improved performance, schedule periodic maintenance (e.g., a weekly cron job running git gc --auto) and consider enabling gc.auto in the repository config.
• If a shallow clone works well, consider using Sourcetree’s Branch filtering or Sparse checkout (via git sparse-checkout init --cone) to limit the working set to the directories you actively develop.

Escalation criteria

• Performance does not improve after applying all checks above.
• Repository size exceeds ~5 GB and core Git operations (clone, fetch, push) remain slow even after garbage collection and LFS tuning.
• The issue reproduces on multiple machines and with different Sourcetree versions (≥ 4.2).
• In these cases, collect:
• Sourcetree logs (Help → Show Logs)
• Repository size and object count (git count-objects -v)
• Exact steps to reproduce (including branch name and operation)
• Open a support ticket with Atlassian, attaching the collected data.

Practical verification

To verify each step, record the baseline time for the problematic operation (use a stopwatch or Sourcetree’s timing tooltip). After applying a check, repeat the operation and confirm the duration drops below the target threshold (≈ 2 seconds) and that the corresponding resource usage (CPU, disk I/O, or network) returns to normal levels.