Diagnosing and Fixing Sourcetree Slowdown in Large Git Repositories

Recognizable Condition

When working with a repository that exceeds roughly 100 000 files or 2 GB on disk, Sourcetree may exhibit one or more of the following symptoms:

• The UI freezes for several seconds after a fetch, pull, or branch switch.
• The file status view shows stale information (e.g., unchanged files appear as modified).
• Refresh operations take longer than 10 seconds to complete.

These signs indicate that the internal housekeeping tasks are becoming a bottleneck.

Cause & Diagnostic Table

Potential Cause	What to Look For in Logs or Behavior
Sourcetree’s built‑in file system watcher scanning every working‑tree file	Repeated "Scanning directory" entries with high elapsed times (often >500 ms) in the debug log.
Embedded Git version lacking recent performance optimizations	The Git version displayed in Sourcetree (Tools → Options → Git) is older than the system Git (git --version) and shows no recent commit dates.
OS‑level file‑event overhead (e.g., macOS FSEvents) persisting after watcher disable	Even after disabling Sourcetree’s watcher, the log still shows frequent file‑event callbacks from the OS.

Ordered Checks

1. Enable debug logging: Open Sourcetree → Tools → Options → General → check Enable debug logging. Restart Sourcetree to start logging to %LOCALAPPDATA%\Atlassian\SourceTree\logs (Windows) or ~/Library/Logs/Sourcetree (macOS).
2. Reproduce the slowdown: Perform a fetch or pull in the large repository and note the UI refresh time (use a stopwatch).
3. Inspect the log: Search for the string "Scanning directory". Record the timestamp delta between successive entries; if many entries exceed 200 ms, the watcher is likely the culprit.
4. Check Git version: In Sourcetree, go to Tools → Options → Git and note the version string. Compare it with the output of git --version in a terminal.
5. Verify OS‑level watcher activity (macOS): Run sudo fs_usage -w | grep FSEvent while Sourcetree is idle; a high rate of events indicates ongoing OS‑level scanning.

Fixes Tied to Findings

1. Disable or throttle Sourcetree’s file system watcher
   • Uncheck Allow Sourcetree to modify your global Git configuration (Tools → Options → General). This stops Sourcetree from injecting watcher‑related settings into .gitconfig.
   • Manually set the Git config that controls synchronous writes: open a terminal and run git config --global core.fsyncObjectFiles 0. This reduces the cost of each file‑system check.
2. Switch to the system Git executable
   • In Sourcetree, navigate to Tools → Options → Git.
   • Select Use system Git version and browse to the Git binary (e.g., /usr/local/bin/git on macOS or C:\Program Files\Git\bin\git.exe on Windows).
   • Restart Sourcetree and verify that the version shown matches git --version.
3. Mitigate OS‑level watcher overhead (macOS only)
   • Increase the FSEvents latency threshold: sudo sysctl -w kern.fsevents_latency=0.5 (value in seconds).
   • Alternatively, mark large static directories as assumed‑unchanged: git update-index --assume-unchanged path/to/large/assets/.

Escalation Criteria

• If UI refresh time remains >10 seconds after disabling the watcher and using system Git, consider reducing the working set:
• Create a shallow clone: git clone --depth 1 .
• Enable sparse‑checkout for directories you actively work on.
• When the repository size exceeds practical GUI limits, evaluate moving to a command‑line workflow for heavy operations and use Sourcetree only for visual tasks like merge conflict resolution.

Verification Steps

1. Repeat the fetch/pull operation and time the UI refresh; aim for <2 seconds.
2. Confirm that the debug log shows a drastic reduction in "Scanning directory" lines (ideally none).
3. Validate that git config --global core.fsyncObjectFiles returns 0.
4. Ensure the Git path displayed in Sourcetree matches the system Git binary.