Software is not responsible for content. Software could help writing better commit messages, but at the end it is the developer who has to improve his messages and mindset.
A shitty text will keep shitty nevertheless if it's written in a simple text editor or in Word π€·ββοΈ
IMO .gitmessage Templates can help - but it's also not the solution. The solution sits in front of the monitor.
@heiglandreas @jetbrains
this post was submitted on 10 Oct 2024
1 points (53.8% liked)
JetBrains
71 readers
6 users here now
A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/
Related Communities
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Copyright Β© 2000-2024 JetBrains s.r.o. JetBrains and the JetBrains logo are registered trademarks of JetBrains s.r.o.
founded 10 months ago
MODERATORS
@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
@heiglandreas @jetbrains are you writing commit messages on a Nokia 3320? Even limiting at 80 had some meaning, but 56 is just an arbitrary low number that sometimes requires an English Masters degree to achieve.
56 characters is ridiculous π We're not in the hole-punching era of computing. We have screens with resolutions that can easily fit 200-300 characters horizontally. My wraps across nearly everything are 100 characters.
Even code at 80 characters I find a joke from the era of 80 character terminals forcing people to have variable names like mCar, pItm, ctx, ptc, hln, vln, l for list, m for map and so on. Sure, it fits in 80 characters, but you might as well be reading obfuscated code.
One more reason why Git-Fork is the GOAT - it does have separate subject and description fields. Don't lump all GUI tools in together and generalize
@Cyno IIRC I explicitly talked about the Jetbrains UI.
Others I didn't check and mean! Sorry if it came across like that!
@heiglandreas @jetbrains What if you want to use Conventional Commits instead of Beams? π
@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.
@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....
Why should I put manual effort into separately maintaining a changelog and a semantically meaningful commit history? If I'm going to manually maintain atomic commits with useful commit messages, why would I want the contents of those messages to be substantially different from the content of the relevant bullets of the changelog?
@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
@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.
The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.
That makes sense to me.
I think I would still argue, however, that for projects using github, gitlab, or any similar forge with a built-in pull-request + code-review feature, there's very limited value in spending time crafting good commit messages in a feature branch. All information that you may be tempted to put there would be more visible and more useful either as code comments (which applies to all projects, not just GH) or as comments in the PR description or discussion. (I also think it's often better to just squash feature branches on merge than to try to maintain a clean branch history while the feature is in development.)
I do think that the commit messages that actually end up on your trunk are important; but, with the exception of the final PR merge (or squash) commit, developers should minimize the time spent writing or thinking about these commit messages.
The one context in which I find details in historical commit messages potentially useful is when using git log -p to figure out when and why something changed. But even then, once I've found the relevant commit, looking up the PR to see if there was any discussion about the change in question is generally the next step; so again, having substantial detail in the commit message itself is unlikely to be helpful.
@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.
@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.
It's not documentation, though. That's my point. It's a byproduct of the development cycle, not a place to store important information.
Commit messages are tied to a commit, sure, but why do you expect developers to have better discipline in writing commit messages than they have in updating code comments?
@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 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!
My point is that "the comments aren't accurate" is also a people problem. And I absolutely disagree that commit messages are "documentation" of anything except the development history.
@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 π
I mean, I've been doing this for over a decade too. If teams are losing data from their issue tracker or source forge, that's a deep problem and not something that can be ameliorated by writing better commit messages.
They are hard to discover⦠and hard to use.
Flippin' fantastic, that's exactly what I want out of my documentation tooling.
I absolutely agree it would be better if forge data were part of the repo itself rather than separate. But for teams that are using a forge in the standard way, they should rely on the forge for this sort of thing, rather than hide important information in an obscure git feature.
@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 π
"trust them" meaning trust github and gitlab?
@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...
To be clear, you're saying you trust git metadata to be preserved even when forge/issue-tracking/etc metadata is not?
I suppose that's probably the case more often than not. I think it's still preferable to trust the forge you use than to spend any significant amount of time or effort trying to ensure that the team has strong enough commit-message discipline to compensate for the risk of losing data in an issue-tracker or forge.
@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
@heiglandreas @ramsey @jetbrains see, that's exactly *why* IntelliJ shouldn't have a default opinion on this. Why wouldn't they choose these conventions? They're popular.
Instead they should have the safest possible default, and let you easily configure your own conventions. When possible, by reading git configuration for anything standard. Which is what IntelliJ already does.
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
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
@heiglandreas @ramsey @jetbrains how do you expect IntelliJ to support this? When if the second line isn't blank?