@BatmanAoD so far I have seen more issue-trackes come and go than VCSs...

So yes: Training developers in commit-discipline would for me not be wasted time and money.

Cause from what I have seen so far the question is not *whether* the issue tracker changes but *when*.

But OTOH: That's just me (and some companies I worked at).

YMMV

@BatmanAoD And the commit message *is* documentation. It explains the "Why" making transparent why the code was written the way it is. If the commit message doesn'T reflect that, then you can also use git commit -m "Fixed issues"

But again: That is then a people problem that no tech will solve!

@BatmanAoD https://phpc.social/@freekmurze/113283034409214370

@BatmanAoD And every developer should take the time to create a meaningful commit-message for the work they did. After all they invested a good amount of time into the code change, so why not proudly explain why they did it, what the challenges where and why they did it
*that* way?

But on the other hand: It's documentation, so just drop it 🙈

Also: Code-comments are fine but tend to rot during code changes. The commit message is always tied to the commit.

@BatmanAoD Having done code archeology for over a decade now I can assure you that the issue with all the information that you need to understand why something was done has been discarded just shortly before due to moving to a different platform... Or something similar.

In any case: Having all the relevant data in one place and not scattered is a huge advantage.

@clovis They already DO support it.

/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.

@jetbrains