Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike on good commit messages (2014)

groups.google.com

Post reply on HN
Print view View original

11–20 of 98 posts

Re: Rob Pike on good commit messages (2014)

#11

Post by nogabebop23 »

amelius wrote: post #8
deanmoriarty wrote: post #4

After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…

Ok, but how much time have you "wasted" wondering what a piece of code was doing versus how much time would you have wasted writing good commit messages?

>> how much time would you have wasted writing good commit messages?

or time wasted writing unit tests, or pull requests, or code reviews?

(1) It's about effective communication. Why do developers appear to care so much about the way we write our code but not the artifacts that form it's ecosystem (and have a much wider audience)?

(2) If you're going to write a commit message, why not take the incrementally very tiny extra bit of time to do it right?

If you don't really care about the quality of your commit messages I'd suggest stop requiring them and allow blank commits. IMO this is preferable over the false impression that a garabage commit history provides any value.

Re: Rob Pike on good commit messages (2014)

#12

Post by nogabebop23 »

pjc50 wrote: post #10
amelius wrote: post #8

Earlier quoted context omitted.

Ok, but how much time have you "wasted" wondering what a piece of code was doing versus how much time would you have wasted writing good commit messages?

I can see what the code is doing. I can't necessarily see why it's doing that and whether it's a bug or a feature. Good messages make ""blame"" extremely useful. It was a constant source of irritation at a previous job where the repository had been imported from a different version control system without history. So half the time "svn blame" would just tell you it was in commit #1 ten years ago, which wasn't nearly e…

>> I can see what the code is doing.

I don't think the reader should have to look at the code to get the summary of what the code does and how it does it.

I agree that the "why" should be the focus.

Re: Rob Pike on good commit messages (2014)

#13

Post by genzeddev »

deanmoriarty wrote: post #4

After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…

I think part of the issue is that for someone who's been writing English for 15 years, knocking out 2 paragraphs of cogent explanatory prose is as easy as ABC.

But for someone who is relatively new to the English language, this can be the source of much anguish and frustration. Doubly so for something like a commit message that is immutable by design. The idea of a typo, a bad idiom, or even worse, unintentionally offensive phrasing, being surfaced for all to see 10 years from now can be a frightening prospect.

I think this whole discussion goes to show the nature of institutionalized privilege, and how seemingly innocent requirements can have a disparate impact on marginalized groups.

Re: Rob Pike on good commit messages (2014)

#14

Post by dtech »

amelius wrote: post #8
deanmoriarty wrote: post #4

After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…

Ok, but how much time have you "wasted" wondering what a piece of code was doing versus how much time would you have wasted writing good commit messages?

It's a balance, but I've definitely seen that a good commit title can massively help newcomers, yourself when you can't remember why something is the way it is and can be a boon when debugging.

A nice balance I've found is to not care while developing, but then squash all commits into a single one when merging a pull request and give that a good message.

Re: Rob Pike on good commit messages (2014)

#15

Post by nogabebop23 »

hprotagonist wrote: post #3

At about the same time, Chris Beams wrote this, which I have loved ever since: https://chris.beams.io/posts/git-commit/ I note with some glee that magit colorizes my commit text and flags long lines,etc. largely in the style of this advice. The money: The seven rules of a great Git commit message Keep in mind: This has all been said before. Separate subject from body with a blank line Limit the subject line to 50 cha…

I shared a variation of this with our development managers (consciously changing "rules" to "tips & suggestions" so as not to ignite a tabs v. spaces holy war) and got very strong responses about how "as long as you get a ummary with some context and cosistency, and the issue # linked this is overkill".

Okay, well how do we enure that we get this without some guidance? It's very frustrating.

Re: Rob Pike on good commit messages (2014)

#18

Post by deanmoriarty »

genzeddev wrote: post #13
deanmoriarty wrote: post #4

After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…

I think part of the issue is that for someone who's been writing English for 15 years, knocking out 2 paragraphs of cogent explanatory prose is as easy as ABC. But for someone who is relatively new to the English language, this can be the source of much anguish and frustration. Doubly so for something like a commit message that is immutable by design. The idea of a typo, a bad idiom, or even worse, unintentionally of…

I can somewhat relate to that, since I am not a native English speaker and it took a while for me to become proficient with the language, but I can say that in the teams I worked in it was mostly a matter of sloppy culture.

Re: Rob Pike on good commit messages (2014)

#19

Post by ben_jones »

genzeddev wrote: post #13
deanmoriarty wrote: post #4

After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…

I think part of the issue is that for someone who's been writing English for 15 years, knocking out 2 paragraphs of cogent explanatory prose is as easy as ABC. But for someone who is relatively new to the English language, this can be the source of much anguish and frustration. Doubly so for something like a commit message that is immutable by design. The idea of a typo, a bad idiom, or even worse, unintentionally of…

> But for someone who is relatively new to the English language

We decided to structure our front-end application using Atomic Design which classifies UI Components in a hierarchy of Atoms, Molecules, Organisms, Ecosystems, and Pages. Pretty universally the definitions of these terms did not translate to many of our remote developers in other countries not only because of the language but likely they didn't have the same Biology education either.

This and other similar revelations have led me to always put myself in the shoes of anyone reading my code, comments, commit messages, and force myself to use simpler language whenever possible.

Re: Rob Pike on good commit messages (2014)

#20

Post by 0xEFF »

amelius wrote: post #8
deanmoriarty wrote: post #4

After being in the field for almost a decade now and guilty of so many poor commit messages, I came to the firm realization that a very important trait of a good software engineer is the ability and diligence to write detailed commit messages, and I would have never remotely imagined this during the first few years of my career (I was "raised" in companies who didn't care at all about this and all commits were always…

Ok, but how much time have you "wasted" wondering what a piece of code was doing versus how much time would you have wasted writing good commit messages?

It's not wasted, sloppy commit messages are correlated with sloppy code.

Thinking through describing the change in prose has an immediate positive impact on code quality.

Post reply on HN