Depending on the size and culture of the team you're working on, I think that requiring detailed commit messages can't really hurt that much. My problem with pl

Depending on the size and culture of the team you're working on, I think that requiring detailed commit messages can't really hurt that much. My problem with playing fast and loose with commit messages is that if you have no standards at all, or very loose standards, when things slip a little bit you can end up with utter garbage -- like a string of commits on a feature/topic branch all with the message '...' which are next to useless (not made up). If you have even slightly stringent standards in place, then when things slip it's not the end of the world. If someone forgets to include the ticket number of a bug or feature, but has relatively detailed commit messages, the messages are still useful. I'm not advocating rejecting pull requests because commit message formatting is off (lines > 80 chars or no short description for the first line, etc), but just paying attention to the stuff that really matters. I think of commit messages like emails to my colleagues. I wouldn't write junk emails that had poor grammar and spelling, or emails that required you to have unreasonable amount of context to understand, and I don't do that with commit messages either.