4 ms·

The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant: > fix: prevent foo from bar

The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant: > fix: prevent foo from bar'ing The whole idea of conventional commit is: > fix: [problem] so the correct conventional commit would be: > fix: foo bar'ing which is succinct and perfectly fine.

chrismorgan 4mo ago
What you describe doesn’t match <https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/>’s examples, or any practice I’ve ever seen. > 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).
- darknavi 4mo ago
  I agree, the default change logging using something like semantic-release would result in this, which feels way off: # Bug Fixes - foo bar'ing
SebastianKra 4mo ago
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.
- jacobsenscott 4mo ago
  You 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". You can do the same when you write commit messages. "Wrap user and account update in a transaction" - "Delete temp files after use".
  - flexagoon 4mo ago
    I disagree. I think the commit description should be "stop the engine wear", not "change the oil". I much prefer commit messages describing why you did the changes, because the explanation of what you did is already there - the code diff itself.
  - SebastianKra 4mo ago
    Whatever describes the change better. Sometimes the issue is easier to describe "fix: car steers in slalom". Where the solution would have been subtle interaction between 3 different components that only occurs in 3rd gear.
0x457 4mo ago
Whole 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).
jacobsenscott 4mo ago
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.
- procaryote 4mo ago
  Arguably "fix memory leak" is why you free the array; freeing the array is just how you fixed it and less interesting as that is also in the diff

chrismorgan 4mo ago

What you describe doesn’t match <https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/>’s examples, or any practice I’ve ever seen. > 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).

darknavi 4mo ago
I agree, the default change logging using something like semantic-release would result in this, which feels way off: # Bug Fixes - foo bar'ing

SebastianKra 4mo ago

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.

jacobsenscott 4mo ago
You 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". You can do the same when you write commit messages. "Wrap user and account update in a transaction" - "Delete temp files after use".
- flexagoon 4mo ago
  I disagree. I think the commit description should be "stop the engine wear", not "change the oil". I much prefer commit messages describing why you did the changes, because the explanation of what you did is already there - the code diff itself.
- SebastianKra 4mo ago
  Whatever describes the change better. Sometimes the issue is easier to describe "fix: car steers in slalom". Where the solution would have been subtle interaction between 3 different components that only occurs in 3rd gear.

0x457 4mo ago

Whole 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).

jacobsenscott 4mo ago

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.

procaryote 4mo ago
Arguably "fix memory leak" is why you free the array; freeing the array is just how you fixed it and less interesting as that is also in the diff