Live data from Hacker News

What a good commit message looks like (2011)

github.com

11–20 of 100 posts

Re: What a good commit message looks like (2011)

#11
post #10
post #3

>74 characters path dependency is hell of a drug.

if you open a terminal window on mac with any kind of display 1080p, 4k whatever with any resolution you will still get a 80x24 terminal by default. Which is the whole purpose of `git log`. Using it on a terminal / ssh session / whatever.

I use ~80 cols terminal because everything is designed to fit in 80 anyway. More than that and it's just whitespace.

Re: What a good commit message looks like (2011)

#12
post #8

Recently, I try to write the first line of my commit messages so they describe what the system now does, compared to before the commit. This makes reading the history much more fun. Like: Validation of email addresses now sends a test email to the user, instead of the old regex that never worked. This style does not work for all kinds of changes, but when it works, it creates a nice history of how the functionality o…

Looks too long to me, will end up looking bad in most things.

Re: What a good commit message looks like (2011)

#14
Should be noted, it is often tempting to describe everything about the change in the commit description rather than comments in the code. Remember, git commits disappear from sight pretty soon and become fossils, whereas there may be something important that should be said in the code itself.

Re: What a good commit message looks like (2011)

#15
post #8

Recently, I try to write the first line of my commit messages so they describe what the system now does, compared to before the commit. This makes reading the history much more fun. Like: Validation of email addresses now sends a test email to the user, instead of the old regex that never worked. This style does not work for all kinds of changes, but when it works, it creates a nice history of how the functionality o…

Including the old bit is meaningless noise there.

I'd use something like "Improve email validation" or "email: send a test email as validation" or such.

The body is where you can describe previous behaviour and give more details.

Re: What a good commit message looks like (2011)

#17

        The body of the commit message can be several paragraphs, and
	please do proper word-wrap and keep columns shorter than about
	74 characters or so. That way "git log" will show things
	nicely even when it's indented.
Software should help me, I shouldn't have to help it. Why doesn't git handle this formatting automatically? I shouldn't need to manually break lines for typographical (not paragraph) reasons.

Re: What a good commit message looks like (2011)

#19
post #14

Should be noted, it is often tempting to describe everything about the change in the commit description rather than comments in the code. Remember, git commits disappear from sight pretty soon and become fossils, whereas there may be something important that should be said in the code itself.

I think that on the contrary, everything should be in the commit. The commit message is dated, it has an author and a context. How often do you come across stray comments which shouldn't be here because the code got refactored away? Commis are often just a git blame away anyway.
Post reply on HN