Examples
Recorded sessions, not reconstructions. Every frame is a command actually executing against a real public repository at a pinned commit: the timings are real latency and the output is whatever the tool printed.
The sessions on the home page are recorded with 0.2.0 against this repository's own history. The ones below were recorded earlier against curl, zod and others, so they show the larger histories the benchmarks use.
A question with nothing to grep for
loading recording…
A real recorded session. Timings are actual latency.
The question shares almost no vocabulary with the commit that answers it — "slow and memory-hungry" against "moving methods to the prototype". Keyword search cannot bridge that, which is the entire reason this exists.
Is this workaround still needed?
loading recording…
A real recorded session. Timings are actual latency.
The highest-value use, and the one with no good alternative. A comment can state a constraint; only history can tell you when it was written and whether it still holds. grep finds the workaround, blame finds who typed it, neither dates the reason.
Who established an area
loading recording…
A real recorded session. Timings are actual latency.
git blame credits whoever last touched a line, so a formatting sweep reassigns authorship. git shortlog counts commits, so mechanical churn outranks design. --owners weights commits by relevance instead.
Measured against both on curl: it agrees with shortlog on the top author and differs in the tail; blame disagrees outright. Which is "right" depends on what you mean by owns, and nothing here settles that.
When something was first introduced
loading recording…
A real recorded session. Timings are actual latency.
Watch what the ranked results are doing here: nothing useful. The answer line comes from the lineage table, not from the ranking, so on a 30,000-commit repository it names a commit ordinary retrieval never surfaces — 3af0e76 is not in the top ten below it.
(by http3) names the token the interval was keyed on. That is what makes the claim checkable: an ordinal resolved by the wrong token is wrong in a way the SHA alone will not show you.
How something evolved
loading recording…
A real recorded session. Timings are actual latency.
Ordinals resolve by ancestry, not timestamps, because rebases and cherry-picks rewrite commit dates on exactly the repositories where the question is worth asking.
When NOT to use this
loading recording…
A real recorded session. Timings are actual latency.
If you can see CompiledFn in the code, git log -S CompiledFn finds its history exactly and instantly. Semantic search returns something adjacent and ranked. Measured on cross-file causal questions: git log -S scores Hit@10 0.950 against this tool's 0.350.
This is on the examples page deliberately. A demo reel that only shows wins teaches people to reach for the wrong tool, and the agent skill shipped with the plugin says the same thing.
An agent choosing for itself
loading recording…
A real recorded session. Timings are actual latency.
Given a neutral list of what exists — git log, git show, git blame, grep, rg, git why — and no instruction about which to use, with gh/curl/wget shadowed so the GitHub API was not an escape hatch.
It reached for history on its own, verified the result with git show, and reported the measured numbers including the one axis that regressed.
Two earlier takes are worth knowing about: in the first, gh was reachable and the agent answered from the GitHub API without touching the repository; in the second, the prompt told it which tool to use, which only proves it follows instructions. Only the third tests anything.
Index management
loading recording…
A real recorded session. Timings are actual latency.
--if-needed is idempotent: about 0.2s when the index is already current, against minutes for a rebuild. Safe to run before any search.