TortoiseGit Shell Integration and Git CLI Log Pagination Interoperability

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:

1. 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.
2. 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:

1. 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.
2. 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.