After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....
After seeing people use the UI to commit to git I understand where all those - sorry: shitty - commit messages come from....
After seeing people use the @jetbrains UI to commit to git I understand where all those - sorry: shitty - commit messages come from....
🙈
An improvement would already be to have a "Subject" line and the text box.
And have the subject line follow the Beams Rule.
Sonthat the first line of the commit message finishes the sentence
"When this commit is applied it will..."
And please: No longer than 56(?) characters (Unicode). Keep it short. You got the textbox to explain *why* in full length.
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@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,lfor list,mfor map and so on. Sure, it fits in 80 characters, but you might as well be reading obfuscated code.
@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?
@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.
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!