@BatmanAoD Because the commit message is a requirement when committing code. The code comment is sitting there and no one cares whether it'S updated.
And a certain schema of a commit message can be enforced. Git hooks for example can be used to make sure that the commit message looks a certain way, has a minimum length, is formatted according to declared standards. As one would do for code-style.
Then they still can just add garbage. But then you have a people problem that no tech will solve
Whether the users then use conventional commits, beams rule, opensavvy, whatever else they want is a completely different question.
And I am absolutely with you that Jetbrains should not favour one over the other.
/cc @ramsey @jetbrains
We might be talking about two different sets of standard. What I would want Jetbrains to support out of the box is the "Subject line, Blank Line, Body" convention that is recommended in the git docs.
People can happily change the defaults to whatever they want but the recommendation from git should IMO be the default.
/cc @ramsey @jetbrains
@ramsey Just: Don't.
The subject lines space is limited and should not be wasted for stuff that doesn't belong there.
Also the prime idea behind conventional commits is to add machine readable info.to the commit message: Fine. Do so. The commit.meysage can be as long as you want. Add it there. Keep the subject line to the human readable part.
Also: Creating changelogs from.git.commits is *not* what chamgelogs are there for.
Keep a changelog can help on *that* front.
@BatmanAoD Oh I am absolutely with you that commit messages document the development history.
And there are valid cases for code-comments (I am a strong proponent of them) when they explain why something is solved in this specific way that would otherwise cause confusion when reading the code! But those tend to suffer from entropy 😁