Tracking Fast-Moving Repos Without Releases

Some GitHub projects are great citizens: they cut releases, tag versions, and maintain a changelog. You can subscribe to releases and instantly see what changed between versions.

Then there’s the other kind: fast-moving repos that mostly just push to main. No tags, no releases, just a stream of commits. If you care about these projects, staying up to date becomes a chore instead of a workflow.

One of the repos that pushed me into solving this was tobi/qmd, a small CLI search engine for your notes and docs that evolves quickly but doesn’t rely heavily on GitHub releases. I found myself repeatedly asking:​

• Did anything important land this week?
• Is it worth pulling main right now?
• What actually changed since the last time I looked?

That’s the gap I built git-digest to fill.

The Pain: “What changed since I last checked?”

My typical “manual” workflow looked like this:

• git fetch across a bunch of local clones
• git log --oneline or git log --since=... on each
• Skim commit messages and mentally reconstruct “the story” of the last few days

It works fine for one repo. It does not scale to 10+ repos you care about. At that point, one of two things usually happens:

• You stop checking regularly and miss interesting changes.
• You keep checking, but it becomes a low-grade, constant distraction.

I wanted something that matched how I actually work:

• I check updates at specific times (morning, end of day, weekend review).
• I want one digest across all the repos I track.
• I prefer a short summary first, details second.

The Core Idea Behind git-digest

The mental model for git-digest is:

“Treat my GitHub repos like an inbox. Periodically summarize what’s new, and let me skim it once.”

The tool does a few key things for me:

• Tracks a set of repos I care about (including those with no releases).
• On a schedule, pulls in the latest commits.
• Keeps track of what I’ve already seen, so I only see new changes.
• Optionally runs the commit list through a local LLM (via Ollama) to generate a short natural-language summary.​

Instead of hopping between GitHub tabs or terminals, I get a single text report that answers:

• Which repos changed?
• Roughly what changed?
• Is there anything I should act on (update, read, test)?

The README covers the full feature list and configuration; what’s more interesting here is how it changes day-to-day usage.​

How I Actually Use It Day to Day

In practice, git-digest fits into my workflow in a few ways:

• Morning snapshot: I run it once in the morning (via cron) so I can scan overnight changes while I’m having coffee.
• Weekend review: A weekly digest shows me the “bigger picture” across projects I follow but don’t touch daily.
• Focused tracking: For specific repos like tobi/qmd, I get a feel for the development direction without reading every single commit.​

The changes-only mode is what makes this sustainable: if there are no new commits for a repo, the digest just says so instead of reprinting the same history. That keeps the signal-to-noise ratio high enough that I actually read it.​

The AI summary is the layer on top that answers, “Okay, but what does this mean?” For example:

• “Refactors around configuration + a small bugfix in search.”
• “Docs improvements and early work on a new feature flagged behind an env var.”

I still have the raw commit list if I want to dive in, but most days, the summary is enough to decide whether to pull, test, or ignore for now.​

Why AI Summaries Help More Than You’d Think

If you’ve ever scanned a page of commit messages like:

• “Refactor X”
• “Fix typo”
• “Minor cleanup”
• “Update dependency”

…you know that the pattern matters more than any single line.

By piping the recent commit list into a local LLM via Ollama, git-digest can:

• Group related commits into themes (“indexing changes”, “API cleanup”, “CLI UX tweaks”).​
• Downplay trivial changes.
• Highlight user-visible behavior changes or risky areas.

You still need to treat it as an assistant, not a source of truth, but for “what kind of work happened here recently?”, it’s a surprisingly good lens.

Letting AI Tools Ask “What Changed?” (MCP)

One extra piece I wanted was to make git-digest usable from inside AI coding tools.

git-digest runs as an MCP server that exposes tools like get_git_updates and list_tracked_repos. That means any MCP-capable client (Cursor, Claude Desktop, etc.) can:​

• Ask for the latest digest on demand.
• Use the report as context to answer questions like:
  • “What changed in my tracked repos this week?”
  • “Did anything touch the indexing logic recently?”

The README explains the setup, but the gist is: I can treat “git updates” as another data source my AI can pull from when needed.​

When GitHub Releases Aren’t Enough

If every project cut perfect semantic releases with detailed changelogs, I might not need something like git-digest. But a lot of interesting tools (including tobi/qmd) move fast and don’t always work that way.​

git-digest is my way of adapting to that reality:

• I don’t have to rely on GitHub’s releases tab.
• I don’t have to remember which repos I checked this week.
• I get a human-friendly summary without giving up the raw commit data.​

If any of this sounds familiar—especially if you’re tracking several “just push to main” style projects—it might be useful for you too.

If You Want to Try It

The README already covers installation, configuration, and all the flags, so I won’t repeat that here.​

You can find the project here:

https://github.com/varunyn/git-digest​

If you end up wiring it into your own cron setup or MCP environment, I’d be curious to see how you’re using it and what you’d like it to do next.