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 otherwis...
For further actions, you may consider blocking this person and/or reporting abuse
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
Hey, I totally understand and appreciate curiosity, learning, etc. But something else puzzles me: does anyone actually look at the number of commits and judge someone’s work based on that? That’s nonsense.
You're 100% right that it’s nonsense, but the scary part is how often that nonsense actually dictates a hiring decision.
I just sat in on an interview where our founder questioned a backend dev with 2 years of experience specifically because he only had 15 commits on GitHub. The candidate had to explain that his professional work belongs to his previous company and these were just personal projects.
Even though his answer was perfectly logical, the fact that he was put on the defensive in the first place proves the point: No matter how much we agree that commit counts are a 'fake' metric, candidates are still being judged by them. It creates this weird tax where engineers feel forced to keep a 'public' presence just to satisfy a recruiter's or founder's surface-level check, even if their real talent is hidden in private enterprise repos.
Phew, good thing I’ve never had to explain my rather moderate activity on GitHub ;)
Ma'am, I agree with you. Judging someone’s work by commit count doesn’t make sense.
What I found interesting while building this was less the metric itself and more the quiet pressure it creates. Even when we know it’s not meaningful, it still influences how we think about our work. The project is really about acknowledging that gap, not endorsing the graph.
Well, when I see that someone has a huge number of commits in their graph, I do tend to think they're "busy" - but I don't draw conclusions about the relevance or quality of their work ;-)
It might not even mean “busy.” A friend of mine was really surprised recently because he found someone’s GitHub account with tons of activity — literally every single day was filled. He kept wondering, how does this person even function? No holidays? No vacations?
Turns out they had a job set up that made a database backup every day 😅
Haha nice one, yeah it means very little, we can agree on that :-)
Oh, I just had to go back to that story and dig up this GitHub profile – it absolutely blew my mind 🤯
Here it is! I think I’m actually going to write a blog post about it next week 😄
I can already see it in my mind’s eye 😄
OMG that's really amazing 😯
I'm really sad for you if you have to "commit daily" instead of just raising a PR whenever your work is done.
m definitely trying it out!
its still the same thing - automated commints, not the real work.. is it?
That’s true. It doesn’t automate real work. The work still has to happen. This only automates a small, mechanical step around it. For me, the value was removing friction and mental bookkeeping, not pretending activity equals output.
❤️
Sounds good.