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
@Cyno IIRC I explicitly talked about the Jetbrains UI.
Others I didn't check and mean! Sorry if it came across like that!
@BatmanAoD Besides that a git log and a changelog have different target audiences.
The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.
And it helps the users if they get a summarized version of what changed for them.without having to.go.theough each commit amd decide for themselves whether and how that internal change affects the exteenal API and then their usage of it.
@Xitnelat Indeed. But software can help.
After all an email editor also has different fields for different content, while it is perfectly possible to write an email.with a texteditor.
And while everything is possible, the "Subject line, empty line, Body (empty line, trailer)" is what it's intended to be.
So why not help the person in front of the monitor with that...
/cc @jetbrains
@BatmanAoD Because they serve a different purpose.
Purely semantically a changelog is something different than a git log (otherwise it would be named a git log).
The changelog is more a log of merges that describes the main overview of new features and also bug fixes.
If I want to know the exact details why this line of code changed, *then* I look at the git log.
Having all atomic commitlogs in the changelog tells the user that you are too busy fixing code to give them a meaningful summary
@ramsey @jetbrains I'm still prepping a talk just about commit messages. The Why, How, what nots and Caveats - experiences from decades of code archeology... 🙈
Might just pitch that to the next CfPs....
@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.
@clovis
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