Skip to main content
Commit frequency counts the commits that touched a file over its walked history. Change frequency alone is a surprisingly strong signal — Tornhill’s central observation is that most code is rarely touched, so the files a team returns to over and over are where structural problems (and future changes) concentrate. In Google’s bug-prediction study, simply ranking files by the count of their bug-fixing commits performed nearly as well as more sophisticated schemes.

​
What mehen emits

​
Semantics

  • Renames don’t reset the count — a renamed file keeps its accumulated commit history.
  • Merge commits are not counted (the git log --no-merges convention): the merged commits themselves are.
  • Each commit counts once per file it touches.

​
How to read it

Raw frequency is context-dependent — a 10-commit file in a young repository can be hotter than a 100-commit file in a decade-old one. Its main use is comparative (which files lead the ranking?) and as the change-frequency input to the hotspot composite.

​
References

  • Tornhill, A. (2015). Your Code as a Crime Scene. Pragmatic Bookshelf.
  • Lewis, C. et al. (2013). Does Bug Prediction Support Human Developers? ICSE 2013 — the “Rahman algorithm” finding on plain frequency ranking.

​
See also

  • Hotspot — frequency × cognitive complexity.
  • Churn — line volume rather than commit count.