Skip to main content
Code churn measures how much a file has changed over its history. mehen ships both variants from the literature:
  • Absolute churn — lines added + lines removed, summed across every commit that touched the file. Matches code-maat’s abs-churn and PyDriller’s (added + removed) variant.
  • Relative churn — absolute churn normalized by the file’s size at the analyzed revision. Nagappan & Ball showed that relative churn predicts defect density well while absolute churn is a poor predictor: 500 churned lines mean something very different in a 100-line file than in a 10,000-line one.

​
What mehen emits

The denominator is family-aware: source-code files use loc.sloc, SQL files use sql.loc.code, Markdown files use markdown.loc.tloc. A file whose analyzer published no line count falls back to a denominator of 1, keeping the value finite and deterministic. history.churn.relative is one of the default mehen diff columns.

​
Semantics

  • Churn follows the file across renames — a renamed file keeps its accumulated churn instead of resetting to zero.
  • Merge commits churn nothing (their first-parent diff would double-count every line already attributed to the merged commits — the git log --no-merges convention).
  • Binary and oversized blobs churn zero lines: anything failing a NUL sniff or larger than 8 MiB is counted the way git log --numstat reports it (-), so a committed archive doesn’t count its bytes as “source lines”.

​
How to read it

​
References

  • Nagappan, N. & Ball, T. (2005). Use of Relative Code Churn Measures to Predict System Defect Density. ICSE 2005. DOI.
  • PyDriller process metrics.
  • code-maat abs-churn (repo).

​
See also