My definition of a perfect commit is any commit that goes to production because only shipping matters.
Many of my projects that use this style of commits are configured so that code is deployed to production every time a commit passes CI.
Maintainability matters. The happiness and health of your peers matters. Security matters. Ethics matters.
The culture of 'only shipping matters' is reflective of the exploitational aspirations of our capitalistic societies, it devalues the bigger picture.
If you only care about getting your code out the door - you're part of the problem.
It gets worse when you have people in critical positions backing bad software engineering practices under business related excuses as this proves nothing but short sighted and the fact that they aren't a good fit for the job as technical debt is going to be waiting around the corner for payback.
P.S. I am assume you do, since you mention commits.
That's circular logic, at best. This is about the label given to "perfect" commit(s), for which someone has made an arbitrary qualitative list of attributes. The GP has a different qualitative list.
It seems, then, that using version control would be unnecessary under that logic. Nothing circular about it.
I prefer good commits, and op does not mind (that is preference) but if shipping is the only thing that matters then why use version control?
IMO, because other factors like collaboration and documentation also matter.
> It seems, then, that using version control would be unnecessary under that logic.
> if shipping is the only thing that matters then why use version control
We're talking about commits here, so there's a given that version control is used. I'm not sure why you are trying to turn it into a debate about the utility of using version control. You're defending what is obviously an overreactive post you made because you chose to interpret the post in bad faith. His values are more product focused than practice focused and there's nothing more.
GL with whatever.