// 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'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
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.
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.
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.
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.
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.
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.