The problem
git log tells you what changed. It never tells you why.
Every senior engineer has spent hours reading through 50 commits
trying to understand a decision made 3 months ago by someone
who left the company.
What GitWhisper does
It installs a post-commit hook that silently captures developer
context at commit time — branch name, recent terminal commands,
IDE state, and the full diff — and stores it as JSON inside
.git/gitwhisper/.json.
When you run:
gitwhisper explain src/auth.rs
It loads the full commit history for that file, pulls the captured
context for each commit, compresses everything into a 12k char
prompt budget, and asks Gemini or a local Ollama model to explain
why the file evolved the way it did.
Why Rust
Single binary. No runtime. Drop it into any repo without asking
teammates to install anything. Cold start is ~12ms.
Interesting engineering problems
The context optimizer was the hardest part. Naively passing full
history blows every model's context window. I ended up scoring
each commit by recency + file overlap + diff size then truncating
greedily until under budget.
Other commands that are useful day-to-day:
gitwhisper owners src/ # contribution-weighted ownership
gitwhisper security src/ # risky change pattern scan
gitwhisper bug-predict src/ # files statistically likely to have bugs
gitwhisper knowledge-risk src/ # bus factor analysis
gitwhisper dashboard # web dashboard at :7878
Current rough edges
- Terminal output is still plain println — colored crate is wired up in Cargo.toml but not applied yet
- Dashboard is single-threaded TCP, blocks on one connection
- Diff analysis is heuristic, no tree-sitter yet
GitHub
https://github.com/SHREESHANTH99/GitWhisper
Would love feedback on the context optimizer approach — happy to
go deep on any of the design decisions in the comments.****
Top comments (3)
The context optimizer is the right thing to obsess over. One refinement on the scoring: diff size is a weak proxy for importance. A two line change that flips a feature flag or bumps a default often explains more of the why than a 200 line mechanical refactor. Scoring closer to information gain, like whether the commit touched a config or a public signature, would beat raw diff size in the greedy pass. Separate flag worth raising: capturing recent terminal commands at commit time is a great signal and also a secret-leak surface, since keys and tokens live in scrollback. Do you scrub before writing the .json, or is that on the user?
Hey Dipankar, thanks for the feedback.
You're totally right about the diff size. A small config change often matters a lot more than a huge automated refactor. Right now the optimizer is pretty greedy just to get things working, but scoring based on information gain (like checking for changes to public signatures or configs) is definitely the next step I want to look into.
About the terminal commands—that would be an interesting signal, but yeah, a huge risk for leaking secrets. GitWhisper doesn't actually read shell scrollback right now; it just uses git diffs, commit messages, and repo metrics. If I ever do add terminal capture, it would definitely need a strict local scrubber before writing anything to the JSON. For now, users can just add files like secrets.json to the exclude_files list in the config.
Thanks again for taking the time to comment. Let me know if you have any thoughts on the best way to handle that information gain scoring locally.
if you like it do star the repo