Background Fetching vs Manual Refresh for large monorepos

Short answer

After a background fetch completes, Tower discards the temporary delta and index structures it built during the fetch, and its internal cache pruning brings memory back close to the pre-fetch baseline — unless the fetch introduced many new refs. New branches and tags are retained in the commit index, so the baseline itself grows in proportion to the number of tracked refs. There is no officially documented hard threshold, but a practical rule of thumb is that once a repository exceeds roughly 1,500–2,000 branches, or individual fetches pull packfiles in the hundreds of MiB (common with heavy LFS usage), the sustained CPU and memory cost of continuous background indexing tends to outweigh the benefit of real-time UI updates. Below that range, background fetching usually adds only a few percent of average CPU overhead and memory settles back within seconds.

What is confirmed vs. likely

Confirmed behavior: background fetching incrementally updates Tower's commit index, which temporarily raises CPU and memory during the fetch and de-indexing phases. When the fetch finishes, transient structures are released and memory trends back toward baseline.

Likely explanation (not officially documented): Tower retains metadata for displayed branches and recent commits while discarding excess delta objects. This is why the baseline stays flat on stable repositories but ratchets upward when a fetch adds a large batch of new refs — the index itself has legitimately grown, so "returning to baseline" means returning to a new, higher baseline.

The 1,500–2,000 branch figure is an empirical approximation, not a vendor-specified limit. It shifts with hardware, disk speed, network latency, and LFS object sizes, so treat it as a starting hypothesis and validate it on your own workload.

How to verify on your repository

1. Open Activity Monitor (macOS) or Task Manager (Windows) and note Tower's idle memory before any fetch.
2. Trigger a fetch (or wait for the scheduled interval). Record peak CPU and memory during the fetch.
3. Wait until the UI is idle again and record memory. If it returns within ~5–10% of the pre-fetch value, pruning is working normally. If each fetch leaves the baseline higher, ref growth is inflating the index.
4. Repeat over a 10-minute window with background fetching disabled (manual refresh only) and compare average memory, CPU, and how often you hit stale branch states during merges.
5. Optionally enable Tower's debug logging to correlate index size changes with the memory trend.

Isolate Tower from other heavy processes when measuring — OS paging and concurrent apps can easily masquerade as a memory leak.

Practical recommendation

• Under ~1,000 branches, modest LFS: keep background fetching on. The overhead is typically small and stale UI state during merges is the bigger risk.
• 1,000–2,000 branches or large LFS packs: measure first using the steps above. If peak CPU saturates a core for more than a few seconds per fetch, or baseline memory climbs steadily, reduce fetch frequency rather than disabling it outright.
• Well above 2,000 branches: manual refresh (or a long fetch interval) is usually the better trade. Accept that you must refresh before complex merges to avoid acting on stale branch state.

One diagnostic detail would sharpen this recommendation: your actual branch count and typical fetch packfile size. If your fetches are small despite the branch count (e.g., a quiet repo with many stale branches), background fetching may still be cheap; if every fetch pulls large LFS-backed changes, even 500 active branches can be expensive.