Hacker News Reader

Comment by codegladiator | Hacker News Reader

Should have been in a doc or wiki instead of commit message.

I have never seen any dev searching for error messages in commit messages.

For the rest of the points (makes smarter, builds trust and compassion), if it's so worthy put it on the blog (like this blog post itself) so it can has a potential to reach some reach some audiance.

View on HN

> I have never seen any dev searching for error messages in commit messages.

I've seen many devs search for error messages in Github search. That often turns up results in people's comments in issue threads, but the search also includes commit messages.

I have had github issues come up for search results frequently, but never a commit message.

But then again, I am not saying "don't write the story". If you think you found something worthy, just write a blog post or even a pastebin/gist would be better in terms of the number of people it reaches.

agreed. My team used to like of extensive commit messages, so that if you had trouble with a piece of code you could just git blame it and take a look at the referred commit.

The problem with that approach is that it doesn't survive as well as you'd like, because fixing a typo in a line would get you "ownership" of the line (since only the last person to change it is blamed). It's even worse in semi-major refactors due to moved/renamed files being treated as new....

Far better to have docs apart.

> fixing a typo in a line would get you "ownership" of the line (since only the last person to change it is blamed).

That's a UI/UX/usability problem with blame, not an inherent one with the practice. Github's blame UI solves this very elegantly (blame history can be traversed easily), as do some others.

> It's even worse in semi-major refactors due to moved/renamed files being treated as new....

This on the other hand is a real problem with Git, but I don't see that it's strictly related to putting context in commit messages. This issue occurs either way.

I think this should have been an issue. Open an issue with the original error, document the troubleshooting in the comments of the issue, then close the issue with the commit.

Why not put it in both?

Commit messages should be short and to the point. I don't want to read a story to understand what this commit did.

1) Just read the title 2) Maybe have TL;DR section for a summary, and details for who cares.

Having a rich commit message is extremely important for capturing code review discussions and design decisions and glue things together for the set of changes in a single place. The advantages far outweigh any negatives from a short commit message that will not give you the "why" of the solution.

Who says this?

I follow the linux kernel guidelines, which have large descriptions in commits. After all these guys wrote git.

Here's linus's take https://gist.github.com/matthewhudson/1475276

“Convert utf-8 to us-ascii to fix error”. Says right there in the commit title, short and to the point.

Absent some automated summarising functionality that produces just the right level of detail for you personally, a concise title and a very detailed commit message that you can skim through to find relevant bits is an eminently reasonable compromise.

Reply on news.ycombinator.com