4 ms·

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 po

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.

chris_wot 7y ago
Why not put it in both?
- codegladiator 7y ago
  Commit messages should be short and to the point. I don't want to read a story to understand what this commit did.
  - l8again 7y ago
    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.
  - UK-Al05 7y ago
    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 https://gist.github.com/matthewhudson/1475276
  - pdpi 7y ago
    “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.
kace91 7y ago
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.
- lucideer 7y ago
  > 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.
lucideer 7y ago
> 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.
- codegladiator 7y ago
  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.
clinta 7y ago
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.

chris_wot 7y ago

Why not put it in both?

codegladiator 7y ago
Commit messages should be short and to the point. I don't want to read a story to understand what this commit did.
- l8again 7y ago
  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.
- UK-Al05 7y ago
  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 https://gist.github.com/matthewhudson/1475276
- pdpi 7y ago
  “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.

kace91 7y ago

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.

lucideer 7y ago
> 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.

lucideer 7y ago

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

codegladiator 7y ago
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.

clinta 7y ago

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.