> ## Documentation Index
> Fetch the complete documentation index at: https://mehen.ophi.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Commit frequency

> How many commits touched a file — the change-frequency half of the hotspot signal.

**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

| Key                        | Type | Description                                                 |
| -------------------------- | ---- | ----------------------------------------------------------- |
| `history.commit_frequency` | int  | Non-merge commits that touched the file, following renames. |

## 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](/metrics/history/hotspot).

## 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](/metrics/history/hotspot) — frequency × cognitive complexity.
* [Churn](/metrics/history/churn) — line volume rather than commit count.