A few weeks ago I posted about building a desktop app that automates GitHub commits because contribution graphs are basically developer mood rings.
Somehow people actually liked it.
Which was unfortunate because now I had to keep improving it instead of peacefully abandoning the repo like nature intended.
So I disappeared back into the codebase and shipped a pretty huge update.
What Changed
Deterministic Scheduling
The app now generates the same commit schedule from the same config every time.
Meaning it finally stopped making random life choices for me.
Old version be like:
"Yeah bro you definitely lock in at 4:11 AM."
Absolutely not.
At 4:11 AM I am unconscious and getting combo attacked by my dreams.
Pattern Learning
The app can now analyze repository behavior and generate commit activity that actually feels natural instead of random chaos spam.
Because fake randomness is still obvious randomness.
Now it feels less like:
"robot discovered GitHub"
and more like:
"slightly sleep deprived developer surviving on caffeine and bad decisions"
Which is the exact vibe I was aiming for.
Better Stability
I moved Git execution into dedicated workers which made the app way smoother overall.
- Less freezing
- Less weird execution issues
- Less me staring at the screen like:
"bro please just push the commit."
Git was acting like I personally offended it.
Internal Refactor
I also cleaned up a huge chunk of the architecture because parts of the old codebase were being held together by pure optimism and side effects.
At one point the logic was basically:
if (works) {
dontTouchIt()
}
Which is not software engineering.
That is survival instinct.
Still Fully Local
- No telemetry
- No cloud execution
- No weird "AI productivity guru" nonsense
- No blockchain
- No "revolutionizing developer workflows" TED Talk energy
Just a desktop app solving the very real developer problem of:
"damn... I forgot to commit again."
Repo
Honestly this project started as a joke and somehow became one of the coolest things I've built so far.
Which is usually how programming works.
You try to build one tiny stupid tool and suddenly you're restructuring worker threads at 2 AM wondering where your life went.
Top comments (7)
"At 4:11 AM I am unconscious and getting combo attacked by my dreams." — I have never felt a sentence more deeply in my entire life. 😂
Moving Git execution to dedicated workers to stop the UI freezing is a massive upgrade. As someone who spends all day writing Python automation scripts and wrestling with local terminal environments, I know exactly how much of a nightmare background execution pathing can be.
Love that you kept it fully local with zero "AI blockchain hype" energy. Dropped a star on the repo—can't wait to see the next refactor! 🚀
So yeah, moving execution into dedicated workers was long overdue. Background terminal handling across Windows/macOS/Linux is basically a full-time side quest disguised as “just run this command real quick.”
Really appreciate the star and the kind words. The goal is simple: keep everything local, fast, and boring in the best possible way. No AI agents buying crypto on your behalf while your CPU sounds like a helicopter.
More refactors coming soon. Hopefully fewer 4:11 AM dream combo attacks too.
hello nice to meet you
An auto-commit desktop app scratches a real itch, the friction of committing often enough is exactly why so many histories end up as one giant "wip" blob. The interesting design tension: auto-commit gives you a safety net and granular history, but you don't want it committing broken or half states as if they're meaningful checkpoints. The sweet spot is auto-snapshots you can squash later, not auto-commits straight to your real branch. I think about that same proceed-vs-checkpoint judgment in Moonshift's pipeline, when is a state actually worth saving. Does yours commit to a scratch branch or stash, or straight to the working branch?
That’s actually a really important design consideration and something I thought about a lot while building it.
Right now the app commits directly to the working branch because the initial goal was reducing friction for personal repositories and maintaining a simple workflow. But I completely agree that automated commits should not be treated as meaningful development checkpoints by default.
I see them more as lightweight progress snapshots rather than polished milestones. A checkpoint or scratch workflow is honestly a direction I’m interested in exploring further, especially with squash or cleanup support before merging into a primary branch.
The interesting part is that building this app slowly turned into a bigger question about what commits are actually for. Are they historical records, recovery points, productivity signals, or collaboration checkpoints? Probably a mix of all four depending on the workflow.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.