Log Filter Performance Limits in TortoiseGit for Large Repositories

Direct answers

No documented commit-count threshold exists. Interactive latency depends on how many commits git log must walk, whether a commit-graph or reachability bitmaps exist, pack maintenance state, and TortoiseGit's own UI rendering—not a single repository size number.

A display limit (-n/max-count) truncates what the dialog shows, not what Git walks. It can reduce UI rendering time once output arrives, but Git may still examine many unmatched commits before finding enough matches for the author/date filter. If the target commit is older than the limit, it will not appear.

No TortoiseGit/Git for Windows version pair is known to reliably worsen or improve log filtering. Newer Git for Windows releases include commit-graph and bitmap optimizations that speed up history walks; very old releases lack them. Treat version pairing as a compatibility concern, not a performance tuning lever.

Why the thresholds are not documented

• Author filters (--author) often require scanning many commits until enough matches are collected, even with date bounds (--since/--until).
• Date filters can prune the walk when commits are sorted by commit date, but topological order or missing commit-graph data forces a fuller scan.
• TortoiseGit adds overhead: loading commit messages, changed-file lists, and diff statistics for every displayed row.

What a commit-count limit actually does

• Reduces the number of rows TortoiseGit must render, which helps UI responsiveness.
• Does not stop Git from walking history past the limit; it only stops output after N matches.
• Can hide the commit you are debugging if it falls outside the most recent N matches.

Practical verification steps

1. Open Git Bash in the repository and time the raw command:

   time git log --author="NAME" --since="2024-01-01" --until="2024-12-31" -n 500 --oneline

2. Repeat with --no-commit-graph to see the index impact, then run git commit-graph write --reachable and git repack -adb and time again.
3. In TortoiseGit → Show Log, apply the same author/date filter and a display limit (e.g., 500). Observe whether the target commit appears and whether the dialog stays responsive. Raise the limit if the commit is missing.
4. Check versions via Help → About in TortoiseGit and git --version, but prioritize repository maintenance over version pairing.

One diagnostic detail that changes the recommendation

Does the repository have a commit-graph (.git/objects/info/commit-graph or .git/objects/info/commit-graphs/) and recent repack? If not, building the commit-graph and repacking usually yields the largest single improvement before any UI tuning.