8
Share
Share on Mastodon
Share on Twitter
Share on Facebook
Share on Linkedin
Aaron Patterson ✅

I guess we need tracking pixels for commit messages so you can tell what your open rate is 🤣

4
1y
Drew 🐘

@tenderlove I see you and I appreciate your commit messages 😉

For real though, while debugging commit messages that provide some context is very, very helpful. Yes, PR discussions help too but it's a matter of signal vs noise. The final commit messages after the PR discussion can achieve a near perfect signal to noise ratio in a way that is super helpful years into the future.

0
1y
Ronan Limon Duparcmeur

@tenderlove if you’re anything like me, 1/ I’m sorry, 2/ how presumptuous of me, and 3/ you cannot help but use commit messages as free mentoring sessions. So it’s less useless doc for future selves (who’ll never read it anyway) and more immediate learnings for code reviewers.

0
1y
Rachael Ludwick

@tenderlove no one reads except that one time when you’re debugging something years later and the long detailed commit message is the one big of info that summons the context needed to figure it out.

0
1y
Paddy O'Brien

@tenderlove nooo
Don’t encourage this. I am sick to death of messages that are “changed variable name”

Well yes, I can see that. Tell me why!?

I’ve long been of the opinion that “what” is the most useless question to ask in documentation and commit messages

0
1y
jjoelson

@tenderlove @searls I find that if I can’t clearly convey the change and its purpose in written form then the change is probably bad.

I forget who said “writing is thinking; to write well is to think clearly,” but I really feel it. I can’t tell you how often I go back and modify the code after trying and failing to write a clear commit message.

0
1y
John Hawthorn :ruby:

@tenderlove I would have written a shorter commit message, but I did not have the time.

0
1y
Keith Gable :whyfox:🇺🇦🌻

@tenderlove as do I. I much prefer “changed X because it didn’t work right last time” to “changed X”

Ultimately the rants and frustration are helpful to read to catch back up, and it doesn’t need to survive into the main branch, so long as you can read it in its detached state. Write long ass descriptions in the pull request which end up getting merged to main. Then reading the history of main covers all of the highlights without you needing to dig in anywhere but the log.

It’s great.

0
1y
Replies