Short answer
Each scroll-triggered batch in TortoiseGit's Show Log dialog is a fixed, source-level constant (commonly cited as 100 commits per fetch), not a configurable value. There is no UI option, registry key, or environment variable that changes it, so the Shell extension cannot signal a desired batch size to Git without modifying and rebuilding TortoiseGit. Prefetching is possible only indirectly, via a git.exe wrapper that serves cached output — a workable but fragile workaround.
What determines the batch size
When you scroll upward in Show Log, TortoiseGit issues another revision-range query to Git (effectively a git log with a max-count and skip/limit derived from the scroll position). The number of commits per request is hard-coded in the log dialog implementation. Because the value is compiled in, the mapping from "user scrolled" to "Git fetch of N commits" is fixed at build time. The stalls you see past ~5k commits are not caused by the batch size itself but by Git re-walking history for each range request on a large DAG, plus the Shell extension's synchronous round trip.
Can the Shell extension request a different page size?
No — not through any supported mechanism. The Shell extension and the Git CLI share only the command line; TortoiseGit constructs that command line internally and exposes no hook for page sizing. To confirm this on your own machine rather than taking it on faith:
- Run Process Monitor (ProcMon) filtered to
git.exe / TortoiseGitProc.exe while scrolling in Show Log. Note the -n/--max-count and --skip arguments — the observed max-count is your effective batch size. - Try setting a plausible environment variable or registry value and repeat the observation. If the command line is unchanged, the value is confirmed non-configurable for your build.
The only clean way to change it is a source patch (adjust the fetch constant in the log dialog code) and a private build — with the ongoing cost of merging upstream security and feature updates yourself.
Prefetching / caching without touching TortoiseGit source
There is no built-in prefetch, but you can approximate one by interposing on the Git executable TortoiseGit calls:
- Warm a cache in the background, e.g.
git log --date-order -n 5000 --pretty=format:%H > %TEMP%\tgit-log-cache.txt, refreshed on a schedule or post-commit hook. - Place a wrapper earlier on TortoiseGit's configured Git path (Settings → General → Git.exe path) that inspects the arguments: for the exact
log invocation patterns TortoiseGit uses, stream the cached output; for everything else, pass through to the real git.exe.
This preserves the scroll-to-load interaction — TortoiseGit still issues its fixed-size requests — but each request is served from disk instead of re-walking the repository, eliminating most UI freezes.
Risks and caveats
- A wrapper can break other Git tooling and may silently mismatch if a future TortoiseGit release changes its argument format. Log every intercepted invocation during testing.
- Stale caches show outdated history; invalidate on ref changes (a
post-fetch/post-merge hook or filesystem watcher on .git/refs). - Prefetching costs disk I/O and memory; on very large repos a cold cache still stalls once.
- The 100-commit figure and the exact constant name should be verified against the TortoiseGit source for your installed version before relying on them — treat them as approximate.
If the wrapper route feels too fragile, the pragmatic alternative is reducing the work per fetch: limit Show Log to a branch or date range, or enable Git's commit-graph (git config core.commitGraph true and git commit-graph write --reachable), which significantly speeds history walks on large repositories and benefits TortoiseGit without any patching.
tortoisegit