Why Commit Canvas?

GitHub shows metrics. Gource shows animations. GitStock shows the last hundred commits. This is the case for focusing on the story itself.

Everyone measures, nobody narrates

Open any repository page and you can find numbers fast: commit counts, contributor graphs, weekly punch cards. The infrastructure for measuring git history is solved. What's strange is how little of it helps you understand a project — what kind of thing it is, what it went through, why it looks the way it does.

A contribution graph can tell you a repository was busy in March. It cannot tell you that March was a rewrite, that it was followed by three months of silence, and that the project nearly died before its most important release. That's not a smaller version of the same information. It's different information.

The tools that exist, and what they choose

There are good tools in this space, and each made a deliberate trade:

• GitHub Insights is the authoritative dashboard — always current, hosted, zero setup. It is built for monitoring, not meaning. Nothing in it is exportable as an artifact, and it only exists while the platform does.
• Gource turns history into a hypnotic animation of a growing file tree. It's genuinely beautiful — and it's a video tool. You watch it; you don't read it, scrub it, or share it as a living page.
• GitStock charts the last hundred commits of a public repo as candles and exports an MP4. Quick, useful, shallow by design — a hundred commits is a sprint, not a story.
• AI summarizers will hand you a paragraph about your repository. Sometimes it's even right. But a summary you can't verify isn't proof of work — it's a vibe.

None of these is doing anything wrong. They're all solving the measurement problem, the animation problem, or the summarization problem. The narrative problem — the whole life of a repository as one honest, shareable, self-contained artifact — is the one nobody picked up.

The bet

Commit Canvas is built on one belief: git history isn't a database. It's a story. Not a story in the fictional sense — a story in the documentary sense. Chapters, silences, comebacks and launches are all physically present in the commit timestamps. The dates don't lie. The work of this tool is to read them honestly and render them beautifully, with every claim traceable to the data that produced it.

That belief drives three design decisions that dashboards can't make:

• The unit is the lifetime, not the calendar year. "Wrapped"-style tools reset every January. A project's defining silence might span eighteen months and two years. The story doesn't care about your fiscal calendar.
• The output is a portable artifact. One HTML file, zero requests, works from a USB stick in ten years. If the story only exists on a platform, the platform owns the story.
• Every claim carries its evidence. "The project went quiet for 43 days" is either true or the tool is broken. There's no room for a language model to improvise, so there's no language model.

What storytelling actually adds

Here's the surprising part: narrative isn't decoration on top of data — it's compression. A chapter strip tells you more about a repository in three seconds than a table of monthly counts does in three minutes, because it encodes transitions: the sprint that ended, the silence that broke, the release that changed the project's shape. Transitions are where projects live.

That's also why the time machine matters. Scrubbing through a life month by month — watching contributors arrive, the codebase swell, the quiet seasons pass — is the closest thing to remembering a project you never worked on.

Who this is for

Maintainers who want a README that opens with something true and beautiful instead of a badge wall. Engineers shipping portfolios who need proof of work, not claims about work. Teams archiving a project's life when it matters. And anyone who has ever looked at a green-square heatmap and thought: I know this is my year, but I can't see it.

The honest limitations

Commit Canvas won't tell you code quality, impact, or whether the project was any good — commits measure activity, not value, and pretending otherwise would be dishonest. Its narrative is deterministic pattern-reading, not literary insight; some repos genuinely have boring stories. And the web version only reaches public GitHub repositories, because it refuses to ask for accounts or keys. Private history belongs to the local CLI, which is where it should stay.

Try it on your own history

The fastest test is your own most-loved repository — the one with the messy middle. Paste it into the story generator or run ./run.sh /path/to/repo anywhere. If the story it finds isn't worth the ten seconds it took to generate, the tool has failed at its one job.