@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 ๐
@BatmanAoD It all depends on the maturity of the toolchain... and the longtime availablility of the external dependencies ๐
And. I no longer trust them further than I can spit... ๐
But YMMV ๐
@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
@BatmanAoD Whatever tool people are using for their issues and/or PRs and/or VCS
And it's not about trusting the tool but trusting that the tool will always be available. Whether due to discontinuation of the tool itself or due to discontinued use of the tool and replacement by something else...