@dominik Have you thought of using build-numbers instead of (ab)using the patch number?

x.y.z+84
x.y.z+83
etc…

But my biggest concern is actually security or size-related. 'Cause how do I provide the data to packagist? I either need separate repositories for those ehich increases the maintenance burden or requires sophisticated automization. Or I provide precompiled “binaries” - which can contain anything. Even code that is not in the repo - a security nightmare…

How did you solve that?

@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 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…

@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 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 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

@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

@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

@clovis

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.

@jetbrains