4 ms·

For anything other than personal projects where messages don't matter much, -m is an anti-patern. Any good commit message should have at least a paragraph expl

For anything other than personal projects where messages don't matter much, -m is an anti-patern. Any good commit message should have at least a paragraph explaining the rationale, functional change and maybe links to design docs or bugs. All the time I come across commit descriptions from decades ago, that are useful because of this.

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 ago
  I 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 ago
  In 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.
deleted 6y ago
[deleted]
rav 6y ago
Git commit messages aren't just messages that you push to whatever central repository; they're also messages for yourself to review while squashing your local history before pushing. I usually make a git commit before testing my proposed change; I don't want to write the full-blown commit message before I know that the tests pass. In that case, -m is very useful to place a marker in the reflog for future reference, even though it won't end up as a message that you share with your collaborators.

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 ago
I 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 ago
In 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.

deleted 6y ago

[deleted]

rav 6y ago

Git commit messages aren't just messages that you push to whatever central repository; they're also messages for yourself to review while squashing your local history before pushing. I usually make a git commit before testing my proposed change; I don't want to write the full-blown commit message before I know that the tests pass. In that case, -m is very useful to place a marker in the reflog for future reference, even though it won't end up as a message that you share with your collaborators.