None of this is as good as "free array memory before it goes out of scope". This is better than `fix: memory leak` - which is what most people would do. It's also better than `fix: free array memory...` because `fix:` is redundant when you have a good message. I get people want to build automation around this stuff, but just do that in a footer of a commit message where humans don't need to see it.
replyWhole idea of CC is to write commits in away that is easy to generate change logs. If you utilize CC correctly or not, at best you get: commit log that harder to read, changelog that is hard to read and still requires you to write highlights (guess minor and path releases are fine).
replyWhat you describe doesn’t match <https://www.conventionalcommits.org/en/v1.0.0/>’s examples, or any practice I’ve ever seen.
reply> fix: prevent racing of requests
Though the example in the actual specification, “fix: array parsing issue when multiple spaces were contained in string”, is more inconclusive (and frankly doesn’t really make sense as a description).
I agree, the default change logging using something like semantic-release would result in this, which feels way off:
reply# Bug Fixes
- foo bar'ing
yep. I'm on the fence about types generally, but "fix:" saves/standardizes a bunch of phrases like "fix an issue where", "prevent" or having to invert the message by describing the solution instead.
replyYou never need to write "fix", or "prevent" if you write a good message. Nobody says "fixed the car by changing the flat tire" or "Go prevent engine wear by getting an oil change today. You say "Change the flat tire", or "Change the oil".
replyYou can do the same when you write commit messages. "Wrap user and account update in a transaction" - "Delete temp files after use".