7 ms·
I personally tend to write pretty short commit messages, I think any important info is better stored either in comments in the code or the module's documentatio
by simias 6y ago
I personally tend to write pretty short commit messages, I think any important info is better stored either in comments in the code or the module's documentation. Who goes digging into old commit messages to understand what a piece of code does? I know I don't.
Not to say that verbose commit messages are a bad thing, it's always better to have too many details than not enough, but I think very long commit messages might also sometimes hint that either the commit is "too big" and should've been broken down in smaller, atomic changes or, as I said above, that you're really just writing documentation and that may be better suited for an other place.
Commits should definitely be descriptive and accurate, but if you break your changes in small chunks you can generally still do that in one or two sentences in my experience.
- Leherenn 6y agoI think long commit messages make sense for bugs, because unless it breaks compatibility you're not going to comment the code every time you fix a bug.
- pacaro 6y agoIn my day job I'm frequently chasing down older code, looking through blame/annotate etc. Commit messages with links to bugs and docs are often the fastest answer to the fundamental questions "Why is this thus? What is the reason for this thusness?"
- u801e 6y ago> Who goes digging into old commit messages to understand what a piece of code does? I know I don't. A lot of people do. If you've ever used git blame on a file, you can see which commit each line in the file is associated with. You can then run git show <sha1> for that commit and see the message and associated diff. Having that information can help you understand why a change was made and may help you avoid introducing regression type errors.
- cameronbrown 6y ago> Who goes digging into old commit messages to understand what a piece of code does? I know I don't. If long-term-ism in commit messages isn't something you care about (which is understandable), then consider short-term benefits. When working with my team, I'm able to read some of their recent commits and understand very clearly what's being worked on, without needing to dive into the code or have daily stand-ups which aren't producing any value on their own. Think of it as an asynchronous way of describing what you're working on, and the broader context.