Essay2026-09-014 min readMuhammad Ahmad

Your git history is a story — you just can't see it yet

Every repository quietly records a narrative: beginnings, sprints, silences, comebacks, and the people who showed up. The problem was never the data. It's that nobody renders it.

Contents

    The flattening

    Open any GitHub profile and you'll see the same thing: a grid of green squares. It's a lovely artifact — compact, scannable, faintly gamified. But notice what it does to a year of your life: it compresses everything into how much. A day is a shade of green. A year is a rectangle.

    The contribution graph answers exactly one question — "was I active?" — and ignores every question that actually matters:

    All of that is in your .git folder right now. It has been accumulating since the first commit.

    What the log actually contains

    A git repository is one of the most honest datasets a developer will ever produce. Not honest in the sense of accurate — people forget things, rebase, squash — but honest in the sense of unguarded. Nobody writes commit timestamps for an audience. The metadata records behavior as it happened:

    Timestamps are the diary you didn't know you were keeping.

    Read as a sequence rather than a sum, the history has structure:

    Reading it properly

    When I started building Commit Canvas, the first thing I did was read raw git logs from well-known repositories. Two things jumped out.

    First: famous projects have dramatic histories. Flask — the Python micro-framework — has 5,600+ commits across sixteen years, and its log contains an early sprint so intense that a single May day in 2017 holds 45 commits. Requests went effectively quiet for years before the PSF-era revival; its own timeline is a story of abandonment and return that its contribution graph never shows at a glance.

    Second: the tools we have flatten exactly the interesting parts. git log --oneline is a stream with no shape. Insights tabs show counts. Video tools like Gource render something beautiful but ephemeral — you watch it once, you can't share it, and it says nothing specific.

    Reading a repository properly means computing over the sequence: month-boundary snapshots, velocity ratios, longest silences, streaks, per-author windows, tag alignment. None of that is hard — it's arithmetic on timestamps. It's just that almost nobody does it, because git gives you plumbing, not narrative.

    Stories need honesty

    There's a trap in this genre, and it's worth naming: the moment you tell stories about data, you're tempted to invent. A tool that says "you're a Night Owl developer!" based on three commits is astrology with extra steps.

    The rule I settled on when building the story engine: every narrative claim must trace to a measurement. "The project went quiet for 43 days" has to correspond to 43 actual days between commits. "Development accelerated" needs a velocity ratio behind it. If the data is thin, the tool should say the story is just starting — not make something up.

    Deterministic beats generative here. You don't need a language model to find the biggest day in a repository; you need a max() and a timestamp. Save the flair for the presentation, not the facts.

    Seeing your own

    There's a specific moment I keep watching people hit when they open a Commit Canvas story for a repository they know well. It's not "cool visualization." It's recognition: "I had no idea my project looked like this — and that is actually my story."

    The years of work already happened. The dataset already exists, sitting quietly in a hidden folder on your machine. The only missing piece was rendering.

    If you want to see yours: it takes one command.

    git clone https://github.com/ahmadrrrtx/commit-canvas
    cd commit-canvas
    ./run.sh /path/to/your-project