Let’s be honest for a second.
GitHub contribution graphs are not a productivity metric.
They are a vibe metric.
I got tired of pretending otherwise, so I built a desktop app that automates commits for me. Not to fake work, but to remove the mental overhead of “oh no I forgot to commit today.”
This app runs locally, schedules commits, and pushes them directly to your repository. No browser tabs. No cron jobs duct taped together. Just open the app, configure it once, and let it handle the boring part.
Why build this instead of just committing manually?
Because consistency is not discipline. It is systems.
I noticed I was writing code regularly, but committing inconsistently. That gap was pure friction. So I removed it.
This project taught me more than expected
how to package a desktop app
how to handle Git authentication cleanly
how to build something people will immediately argue about
And honestly, that last part is the fun one.
You can judge the idea, but the app works. It ships. It solves a real annoyance.
Here is the repo
https://github.com/TROJANmocX/-Auto-Commit-Desktop-App.git
Curious question for you
Do tools like this reduce discipline or reveal how fake our productivity metrics already are
Top comments (31)
I've been working on a side project for a few weeks, outside of my day job. I've been stuck on a certain piece so I haven't committed to it in a few days, been spending my free time debugging even though I've been working on it over a few days.
Commit graph isn't a measure of productivity, just as lines of code isn't.
Any company that equates the two is probably not worth working for!
I definitely agree. In fact, many large companies leverage CI/CD pipelines to collect performance metrics for stack ranking and engineering evaluations.
We loved your post so we shared it on social.
Keep up the great work!
Many people tell me, "How hard is it to just manually commit once a day?" But it's not about difficulty; it's about 'mental bandwidth'. Just as CI/CD exists to free our hands, automated committing exists to free our minds. Consistency should be a function of the system, not a test of willpower.
If a metric can be so easily automated, it shouldn't be used as a standard for evaluation in the first place. If you feel this tool 'ruins' the contribution graph, is it possible that the graph was already broken?
I agree to the comments stating that frequency of commits should not be used to measure work. I can also understand that people do weird things if they are happened to be measured like this.
What I am seeing in this discussion about whether doing one commit a day manually or automated is that apparently lots of people don't understand how to use a revision control system effectively. A revision control system should not primarily be a backup tool that prevents loss of the previous day's work. Instead it should cluster and explain logical units of work to allow other people (and your future self) understanding your work. So, instead of committing in certain time periods, in which you might have done multiple, unrelated changes to the codebase you should make commits, whenever you think you completed a small logical task, like implementing a functionality, fixing a bug, etc. When you do so, you should write a good commit message, describing on a high level what you did and why you did it, such that other readers of that commit (and yourself in the future) can understand what the change attempts to do. This will also help to judge the sanity of your change, which is often impossible if a reader find a weird change and has no idea on what you attempted to achieve. I also recommend using the time when writing this commit message to reassess your changes: Does the change really do what you are describing? Does it do anything else, which probably should go into a separate commit or should be even undone before committing (like weird printf debugging). Following this approach will drastically improve the quality of your codebase over time. And very likely it will also improve your personal discipline.
Committing is not boring, it’s versioning your work, you don’t automate it except you are not doing anything serious
Get out of my code buddy
Your response to someone about someone who had a filled commit history from just backing up a database has me wondering, though I also suspect this is true by necessity, but does it only commit if there are actual changes to commit? So like, if I set up semi random daily commits, and then I don't work one day, does it just skip that commit?
Consistency isn’t discipline, it’s systems — agreed.
The real issue isn’t auto-commit vs manual commit, it’s what we choose to measure.
GitHub graphs were never designed as a productivity signal, yet we collectively turned them into one. Your tool doesn’t fake work — it exposes how shallow the metric already is.
From a systems perspective, this is just friction removal: writing code ≠ remembering to perform a symbolic action every 24h.
The only real risk is when the signal replaces the substance. As long as commits remain traceable to real changes, automation here is no different from CI, linters, or scheduled jobs.
In short: this doesn’t reduce discipline — it reveals where discipline was never the bottleneck.
Curious to see how people react when a “vibe metric” gets optimized like any other system.
Wait if you don't commit often, how u manage version control.
Most of the time I don't revert my files but sometime I need to because AI messed up my code or i don't remember what decision i made that time.
If I m wrong, sorry but if I missing something, do tell me...
Liking instantly for the yui thumbnail lol
hhh me too
HELLL YEAHHHHHHHHHHHH...!! hope you like the project too.
Oh yeah the project looks great! Will definitely use it when I get time for my personal projects... (o′┏▽┓｀o)
Bingo! This totally works!
Kudos buddy
Some comments may only be visible to logged-in visitors. Sign in to view all comments.