On this page
Git intelligence is the practice of mining a repository's commit history to find risk the source code alone cannot show: which files break most, who holds the knowledge to fix them, and which files quietly change together. The four signals are hotspots, ownership, bus factor and change coupling. Run repowise init and all four are computed from git log and git blame, with no LLM key and no network calls.
What is git intelligence?
Git intelligence reads change over time, where static analysis reads one snapshot. Every commit records who changed what, when, and alongside which other files. Aggregated, that record exposes patterns no single revision shows: a file rewritten eleven times this quarter by four people, or a backend route that always drags a frontend file along with it.
The idea is not new. Adam Tornhill's book Your Code as a Crime Scene and the tool behind it, CodeScene, popularised hotspot analysis from version-control data. What has changed is where the signals show up: in the CLI, in pull requests, and in the context an AI coding agent receives before it edits a file.
uv tool install repowise # or pipx / pip install repowise
repowise init # git signals are computed during indexing
Hotspots: change frequency meets bug history
A hotspot is a file that changes constantly and keeps needing fixes. Complex code that nobody touches is stable debt, and churn in simple code is cheap. The risk lives in the overlap, where every edit to hard-to-reason-about code can cause a regression.
repowise ranks hotspots from change frequency and prior bug-fix commits over full git history, relative to the rest of the repository, so "hotspot" always means hot for that codebase and not past a universal threshold. A bug fix is a commit whose subject matches fix, bug, patch or closes #N, minus docs, typo, bump and chore commits.
repowise risk --target src/auth/session.py # history, owner, bus factor for one file
repowise health --file src/auth/session.py # findings for one file
An untested hotspot is a hot file with low test coverage. repowise intersects the two when you supply a coverage report (LCOV, Cobertura, Clover or JSON), which makes them the cheapest failures to prevent. The git hotspot analysis guide shows how to read the ranking, and untested hotspots covers coverage.
Ownership and bus factor
Bus factor is how many of a file's top authors it takes to cover 80% of its commits. A value of 1 means one person wrote at least 80% of the history: a knowledge silo. A value of 0 means no history was indexed for the file, not that it is safe.
Ownership is computed per file from git blame (the author of the most surviving lines), with the recent owner, the person with the most commits in the last 90 days, shown beside it when they differ.
repowise context src/auth/session.py --include ownership
"ownership": {
"primary_owner": "Dana Lee",
"owner_pct": 0.71,
"contributor_count": 4,
"bus_factor": 1,
"recent_owner": "Sam Ortiz"
}
Three code-health detectors turn this into findings: knowledge_loss (a file still changing whose bus factor is 1 and whose main author has gone quiet), ownership_risk (many drive-by authors and no clear owner) and developer_congestion (too many hands on a busy file). A module is flagged as a silo when one person owns more than 80% of its files. Ownership means authorship, not responsibility, so read it as a map of knowledge, not a performance review. See code ownership and bus factor.
Change coupling and co-change
Change coupling is the tendency of files to change in the same commits even when neither imports the other. Co-change is the raw count: file A and file B appeared together in N commits. Once that count is high enough, it points to a hidden contract such as a shared serialization format, or a client that must move whenever an API route does.
Static analysis cannot find this, because the dependency exists in history and not in the syntax tree. repowise keeps co-change edges apart from import edges on purpose, so an edit pattern never pollutes the dependency graph. It surfaces them as coupled partners on a file and as missing_cochanges on a diff, so a reviewer is warned when a PR touches one half of a known pair.
get_risk(changed_files=["src/api/routes.ts", "src/middleware/cors.ts"])
The hidden coupling guide separates real evolutionary coupling from migration noise.
The four signals at a glance
| Signal | Question it answers | History it reads | Static analysis can produce it? |
|---|---|---|---|
| Hotspot | Where is change risk concentrated? | Change frequency and bug-fix history | No |
| Ownership | Who understands this file? | Authorship and blame per file | No |
| Bus factor | How few people hold that knowledge? | Share of commits per author | No |
| Change coupling | Which files move together? | Files edited in the same commit | No |
Scroll the table sideways to see every column.
Where the signals show up
| Surface | What you get |
|---|---|
| CLI | repowise risk, repowise context --include ownership, repowise health |
| MCP | get_risk, get_context and get_overview carry hotspot, owner and co-change fields to your agent (repowise ships ten MCP tools) |
| Pull requests | get_risk in PR mode lists missing_cochanges and recommended_reviewers |
| Dashboard | Hotspots, Owners and Change coupling pages |
Scroll the table sideways to see every column.
History also feeds the health score. The evolutionary detectors (churn, ownership concentration, co-change) sit next to structural ones in the defect-risk score, which reaches a ROC AUC of 0.74 at predicting which files get bug-fixed over the next six months on repowise's open 21-repository benchmark. Method and data are on the benchmarks page.
Pitfalls
- Shallow clones hide history. Owners and bus factors describe only the commits fetched. Run
git fetch --unshallowbefore indexing. - Squash merges credit one author. Co-authored-by trailers do not count toward ownership.
- Move commits are not authorship. repowise ignores commits that only move a file, and
repowise init --follow-renameskeeps ownership across renames. - Small teams are naturally single-owner. The
small-teamprofile in.repowise/health-rules.jsonlowers the ownership detectors to low severity. - Coupling is a hint, not a dependency. A bulk rename or a lockfile bump can couple unrelated files, so look at the commits behind a pair.
Go deeper
FAQ
- What is git intelligence?
- Git intelligence is the analysis of commit history to derive engineering risk signals: hotspots, code ownership, bus factor and change coupling. It treats every commit as evidence about how a system really evolves, which a snapshot of the source cannot show.
- How is a hotspot different from a complex file?
- A complex file that never changes is stable debt. A hotspot changes often and keeps needing fixes, so each edit risks a regression. repowise ranks hotspots relative to the rest of the repository.
- What is bus factor and how does git history estimate it?
- Bus factor is how many people would have to leave before an area has no informed maintainer. repowise computes it per file as how many of the top authors it takes to cover 80% of the file's commits. A value of 1 means one person wrote most of it.
- What is change coupling, and why can't static analysis find it?
- Change coupling is files that change together across commits without importing each other. The link lives in history, not in the code's structure, so a parser cannot see it. You have to mine commits.
- Does git intelligence need an LLM or a network connection?
- No. repowise computes ownership, hotspots and co-change from
git logandgit blameduringrepowise initandrepowise update, with no LLM key and no network calls. - Are these signals predictive of bugs?
- Yes, as part of a blended score. On repowise's open 21-repository benchmark the health score reaches a ROC AUC of 0.74 at predicting which files get bug-fixed over the next six months, using only history up to the scoring commit.
