// code-churn-forecaster

Paste a git log and get back a ranked map of which files are most likely to change next. The forecaster computes per-file commit activity, churn, recency-weighted activity, author entropy, and fix ratio — then blends them into a 0–100 change-risk score with an interactive heatmap across the log's time span.

git log --numstat --date=short --pretty=format:'@@@%H|%an|%ad|%s'
Ctrl/Cmd + Enter to analyze0 lines · 0 chars
◷

Paste a git log above to forecast which files are most at risk of change

Parses custom and default git log formats — analysis runs entirely in your browser

// how-it-works

01

Commit activity

The forecaster counts how many commits touch each file. Busy files that change often carry a higher chance of changing again — the volume of past churn is a standing bias for future work.

02

Recency weighting

Each touching commit contributes 0.94 raised to its age in the log — the newest commit counts fully, older ones decay. A file edited this week scores far higher than one last touched months ago, because change tends to cluster.

03

Author entropy

Shannon entropy in bits measures how spread out edits are across authors. A file touched by many different people is likelier to collide, conflict, and churn than one owned by a single steady author.

04

Fix ratio

The fraction of a file's commits whose subject mentions fix, bug, hotfix, patch, revert, or similar is a signal of defect churn — files repeatedly patched are more likely to be reworked than files changed by clean feature work.

05

Risk blend

Each signal is min-max normalized across files and blended: activity 30%, recency 30%, author entropy 15%, fix ratio 15%, churn 10%. The result is a 0–100 score and a band from low to critical.

06

Heatmap binning

Commits are binned into 12 even windows across the log's date span, and each cell shows how many commits touched that file in that window. If dates are missing, binning falls back to commit order.

// known-limits

!

Instability, not defects

This is a heuristic over past change patterns. It predicts the likelihood that a file changes again — it does not predict bugs, outages, or the quality of the code in any file.

!

Not a statistical model

It is a static text analyzer with hand-chosen weights, not a trained model. The 30/30/15/15/10 blend is a reasonable starting point, not a proven optimum.

!

Depends on your log

Results reflect only the commits you paste. A shallow log understates risk; merges, formatting-only commits, and generated files can skew counts. Pass the full history for a more meaningful picture. Scores are relative: each signal is min-max normalized against the other files in the same log, so a score of 100 means "most changed file in this input", not an absolute defect probability.

!

Parsing caveats

Binary file rows count churn as zero. Rows that do not match the expected numstat shape are skipped and reported in the warnings. Dates drive recency; when absent, commit order stands in.