perf: resolve stale-file last-touch with one git walk - #203
Merged
Merged
Conversation
…0 files Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
hotspots-research/docs/promotion-briefs/last-touch-single-walk.md.git.rs::batch_last_touch_for_filesresolveddays_since_last_changefor files with no commit in the 30-day window by running one full-history, path-limitedgit log -- <500 paths>per 500 files. Each call walks the whole history, so--touch-mode filecost grew with history length times stale files: 232s on vscode, of which the fallback is essentially all (the 30-day window query itself takes 0.01s).git log --format="COMMIT %ct" --name-only --until=<as_of>walk. Signature and value semantics unchanged.Behavior note (intended)
The old path-limited walk applies git history simplification, which can prune a side-branch commit at a merge that is TREESAME to the first parent. The single walk sees those commits, so a value is never older than before and is occasionally more recent. In the vscode POC 28 of 14,247 stale files differed (0.2%): 23 strictly more recent, 5 within a day, 0 older. On linear history the results are identical. A fixture test documents the difference.
Test plan
-s ours): new never older than old;f.txtold 10 days, new 8as_ofignored; files absent from history omitted; empty input spawns no gitcargo test --workspace(555 in hotspots-core),cargo fmt --check,cargo clippy --workspace --all-targetsclean--touch-mode file:days_since_last_changeidentical for every function on this repo (982), scikit-learn (3,826) and vite (2,102), none larger; wall time 2.2s->1.6s, 9.3s->4.9s, 2.2s->1.0sNot in scope
core.quotePath), so such files never matchstale_filesin either method. Noted in the brief as a separate change.🤖 Generated with Claude Code