3 ms·

of course no one reads your commit messages if they're useless!

by juped 3y ago

lmm 3y ago
I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.
- ajkjk 3y ago
  Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
  - lmm 3y ago
    > If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that. > But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction. This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.

of course no one reads your commit messages if they're useless!

by juped 3y ago

of course no one reads your commit messages if they're useless!

lmm 3y ago

I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.

ajkjk 3y ago
Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
- lmm 3y ago
  > If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that. > But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction. This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.