3 ms·
"refactor: changed stdout statements" is a useless commit message. I should not have to manually open the commit to find out what was actually changed. The mes
by intertextuality 7y ago
"refactor: changed stdout statements"
is a useless commit message. I should not have to manually open the commit to find out what was actually changed. The message should specify changed X to a. If it's too long, that's what the git commit description is for.
The keywords are also redundant. I don't need to see doc) if the rest of the commit message reads "update README". That's obviously documentation.
"style: black to files"
??? all that was changed was styling here with newlines and quotes. [0]
---
To be frank, it's not that hard to write a good commit message. It just requires you to use your brain for more than .2 seconds to write a good, concise summary. Forcing yourself to do this also in turn makes you write better (concise, focused) commits instead of just shutting off your brain and following some tool.
[0]: https://github.com/Woile/commitizen/commit/9cecb9224aa7fa68d4afeac37eba2a25770ef251 https://github.com/Woile/commitizen/commit/9cecb9224aa7fa68d...
- woile 7y agoOh wow, it's good to have some feedback, I do my best to write something explaining what changed, and what would make sense for someone reading that is not me, I guess I have to try harder. I do not agree that the tool makes you lazy, I think it actually forces you to write something, I've seen many other popular repos (like requests) that don't follow any conventions and they have commits like "fixed stuff", "more changes", etc. The prefix on the commit has the benefit that you can parse it and use it for something else, like to generate the semver, this doesn't mean you have to use conventional commits, but any convention. With commitizen you can make your own rules, and make it easy to share with new colleagues, it's better than pointing to a useless confluence lost in space and time, that was my idea at least.