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

1–10 of 98 posts

Re: Rob Pike on good commit messages (2014)

#2

Post by caiocaiocaio »

One one hand, I like a nice long commit message. On the other hand, human nature is terrible.

I know that if long commit messages catch on, some synergetic managers will start insisting on minimum lengths for commit messages, and start having meetings discussing standards and policies for commit messages, and start filling binders with more rules than one person could ever memorize. Soon, fixing a single-character typo in a comment will take 20 minutes, and pressing enter will be nerve-racking because you know there's just something you're forgetting from the binder.

Re: Rob Pike on good commit messages (2014)

#3

Post by hprotagonist »

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 characters

    Capitalize the subject line

    Do not end the subject line with a period

    Use the imperative mood in the subject line

    Wrap the body at 72 characters

    Use the body to explain what and why vs. how*

Re: Rob Pike on good commit messages (2014)

#4

Post by deanmoriarty »

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 "add x", "fix foo", "fix build", ...). It became way too frustrating when I looked back at code committed by myself (or others) years prior and wondered "what is the reason why this code exists?"

These days, every single commit I push has an entire paragraph or two clearly describing the changes, and the motivation behind them, even if it's a one-line diff.

My team praises me for this, and I think I've been able to influence the culture as I see more junior people taking their time to craft good commit messages and edit their commit history before pushing a PR.

Re: Rob Pike on good commit messages (2014)

#8

Post by amelius »

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?

Re: Rob Pike on good commit messages (2014)

#9

Post by deanmoriarty »

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 has been an obvious net time gain for my projects. I do a lot of system programming, and often there are very complex reasons why a particular function is called in a non-obvious way, especially after tricky bugfixes. Having a somewhat detailed written record associated with the commit, that won't rot like an inline code comment would, has been very useful in my experience. And all my thoughts become instantly available to all the future code readers, who will most likely not be me.

Re: Rob Pike on good commit messages (2014)

#10

Post by pjc50 »

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?

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 enough.

Post reply on HN