SourceTree commit graph pagination for very large histories

When working with repositories that exceed 100 k commits, SourceTree’s Log/History view appears to load commits incrementally, but the exact mechanics and limits of this pagination are not documented. The UI offers a Limit filter that caps the total number of commits retrieved, yet it does not provide a way to adjust the size of each incremental fetch or to enable true cursor‑based paging. The internal virtualized list seems to request batches of roughly 100 commits, but this value is not exposed through any settings file or Git configuration. Additionally, the initial topological sort can stall the UI for large, merge‑heavy histories before virtualization takes effect, and the behavior differs between Windows and macOS builds. The goal is to understand whether and how SourceTree allows control over the commit-fetch batch size, and how the topological sort interacts with the virtualized list.

• Does SourceTree expose any setting to adjust the per‑request commit batch size?
• If not, can the internal pagination algorithm be overridden via a Git config or environment variable?
• How does the topological sort interact with virtualization when the history exceeds 100 k commits?