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

41–50 of 98 posts

Re: Rob Pike on good commit messages (2014)

#41

Post by SkyPuncher »

Pxtl wrote: post #39

We take a "PR all the things" approach using MS VSTS/DevOps. Every PR needs a work-item attached and a description, and those get cooked into the commit. We always squash, but squashing is dubious - if the any of the commits of the branch are still kicking around in other branches, it looks like they're ahead when they're not. Imho, this is a huge flaw in GIT - I don't want to squash, but I do want a clean history an…

Isn't that what rebasing is for?

We rebase all of our feature branches for PR's.

Re: Rob Pike on good commit messages (2014)

#43

Post by MayeulC »

I also encourage everybody I know to write descriptive merge commits: "Merge feature X" instead of "Merge someone/master into master". It really helps when using

    git log --first-parent
to avoid displaying intermediate messages.

This really helps with the so-called "Aligator" [1] workflow: create a merge commit for every bugfix or feature, instead of just rebasing (you can still rebase if you want). That makes the history contain more metadata: a bit like a HN or e-mail thread can be collapsed to filter it out, first-parent helps filter the noise (implementation details) to display topics.

I wish web UIs such as gitlab's allowed to collapse commit graphs according to this.

[1]: https://euroquis.nl//bla%20bla/2019/08/09/git-alligator.html (no mention of first-parent in that blog post, unfortunately.)

Re: Rob Pike on good commit messages (2014)

#44

Post by SkyPuncher »

Personally, I find little use to stashing a lot into a commit message. Nearly all work is managed outside of Git.

Provide a short description, reference the work you're doing (a ticket, a PR, etc), and hold the discussion there.

Rebase many, meaningless commits into a single one for integration purposes.

Re: Rob Pike on good commit messages (2014)

#46

Post by Pxtl »

SkyPuncher wrote: post #41
Pxtl wrote: post #39

We take a "PR all the things" approach using MS VSTS/DevOps. Every PR needs a work-item attached and a description, and those get cooked into the commit. We always squash, but squashing is dubious - if the any of the commits of the branch are still kicking around in other branches, it looks like they're ahead when they're not. Imho, this is a huge flaw in GIT - I don't want to squash, but I do want a clean history an…

Isn't that what rebasing is for? We rebase all of our feature branches for PR's.

Yeah, I just mean the PR process auto-squashes/rebases instead of merging, so that junior developers don't have to think about it.

The problem is that if somebody leaves the branch up (delete-on-merge is obviously preferred), or derivative experimental branches, you can't tell if it's been merged or not because the commit hashes are different after the rebase. The branch list has become a scary basement.

Re: Rob Pike on good commit messages (2014)

#47

Post by iudqnolq »

getpolarized wrote: post #28
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've been a Software Engineer for 15 years now... 10 years in the industry as a systems engineer before that. I sort of agree but what I try to do is put more comments and documentation in the source code directly. The problem is that commit messages are usually hidden only when there's a problem. Comments are there for the life of the code. The problem with comments though is that they could go stale and something c…

Jetbrains can be set to show you the last commit message that modified a chunk of code. I assume there's a way to do this in vim/emacs for the sufficiently motivated as well.

Re: Rob Pike on good commit messages (2014)

#48

Post by practical_lem »

mcslearner wrote: post #17

> What's really sad is how often I find myself telling people this. It should be part of our culture... Somehow I don't think whining about this problem on some google group is going to help.

It isn't "some google group", it's the golang-dev mailing list.

Re: Rob Pike on good commit messages (2014)

#49

Post by iudqnolq »

jgalt212 wrote: post #40
tuckerpo wrote: post #34

I follow the format of the first line being a tag with a short one line description, followed by a new line, followed by further explaining of the what and why. Example: "Fix: router now asynchronous. Our previously implementation of a synchronous router was causing a 30% slowdown when tested with `wrk` (hyperlink to utility used to test)." with an additional link to a Jira ticket if the particular commit addresses o…

this makes perfect sense and one should show care when constructing commit messages. That being said, if commit messages require too much care, then folks will start to make less commits as they become rather expensive to do. As with all things in life, when and how often to commit is a balance.

What do you think about committing with one-liners as you develop so that you can rollback, and then completely rewriting history before pushing?

Re: Rob Pike on good commit messages (2014)

#50

Post by RussianCow »

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…

> Limit the subject line to 50 characters

It's nearly impossible to get certain points across in 50 characters. I keep mine under 72, and even then, I sometimes struggle to adequately describe a change in that little space, even at a high level, to the point that it would be useful for someone searching for something.

Honestly, all of this stuff matters way less than the actual content of the commit message anyway. Style is worthless if there is no substance.

Post reply on HN