Repository navigation
Backfill real star/fork history instead of starting from one dot - #3
Merged
Merged
Conversation
GitHub exposes when each star/fork happened (starred_at on the stargazers endpoint with the star+json media type; created_at on each fork), so instead of waiting weeks for daily repo_stats snapshots to build a trend, reconstruct the real historical curve right now and backfill every day since the first star/fork. Confirmed on gitgalaxy: 119 days of real history (3 stars on 2026-04-04, growing to 46 by today), instead of a single point. Re-derived from the live list on every run (not a one-time backfill script), so it's self-correcting: a missed day heals itself, and an unstarred repo's historical curve adjusts down too, which is more honest than a frozen snapshot would be. Known, unfixable caveat: only sees currently-existing stars/forks -- one that was later removed/deleted won't appear in today's list, so a historical peak before a removal is invisible (GitHub doesn't expose removal events). Also fixes a mislabeling from the previous PR: "Unique Cloners (14d)" implied each point was a rolling 14-day window. Checked GitHub's docs directly -- traffic/clones returns one entry per CALENDAR DAY (GitHub just only exposes the trailing 14 days of them at any given time). Relabeled "(daily)", and added an explicit code comment on why these two series are deliberately NOT cumsum'd the way stars/forks are: summing daily "uniques" across days double-counts anyone who visited on more than one day, since GitHub's per-day uniqueness aggregate retains no cross-day identity to de-overlap against. There is no valid transform that recovers true cumulative-unique-visitor counts from these aggregates -- an information-theoretic limit, not a data-processing gap (the same repeat-visitor inflation already exists, less visibly, in the pre-existing "Cumulative Downloads" chart's own cumsum of daily unique_cloners -- flagged, not touched here). Tested end-to-end against a scratch copy of traffic_metrics.db: full fetch_and_store() run, 119 backfilled repo_stats rows for gitgalaxy matching the real stargazer/fork timestamps, all 6 charts render without error.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
starred_atvia the stargazers endpoint'sstar+jsonmedia type;created_atper fork) instead of only ever having today's snapshot. Confirmed on gitgalaxy: 119 days of real history, not one dot.unique_cloners— flagged in the commit message, not touched in this PR.)Testing
Full
fetch_and_store()run against a scratch DB copy — 119 backfilledrepo_statsrows matching real stargazer/fork dates, all 6 charts render without error.🤖 Generated with Claude Code