@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 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 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.
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
@Cyno IIRC I explicitly talked about the Jetbrains UI.
Others I didn't check and mean! Sorry if it came across like that!
@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?