4 ms·

I think it helps to think about when people read the commit messages, and when commits impact workflows. Having tons of commits that are partially broken ("savi

I think it helps to think about when people read the commit messages, and when commits impact workflows. Having tons of commits that are partially broken ("saving work") can make it harder to git bisect. I sometimes read commits to understand what's being worked on, again "saving work" is just noise. People on the Ops side, doing packaging, or deployment often care more about the commit messages. A good commit message can help them avoid looking at a diff, or understanding which commits need scrutiny.

j4yav 3y ago
I spent most of my career in ops, specifically packaging and deployment, and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie.
- radiator 3y ago
  For some codebases, if you are lucky, you can trust commit messages from specific trustworthy people. Diffs might not lie, but they take much more space and time to read than 'git log --oneline'.
- tivert 3y ago
  > ...and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie. That's a sentiment that's very easy to take too far, and shy people away from valuable commit message practices out of misplaced perfectionism. Diffs definitely can lie. Not about the way it is, but about the way it should be. Commit messages are insanely valuable, and often convey important information that's impossible or unreasonable to communicate in any other way (for instance, things like like intent and rationales). Diffs can say ABCD, commit messages can say CDEF. They all should be considered, together, but with a reasonable dose of skepticism, when you're figuring something out. Some things that are true (if you're system lives long enough): 1. There's a good chance your documentation wiki will get purged or severely corrupted in some migration before you lose your commit messages. 2. There's a good chance your ticket system will get purged or severely corrupted in some migration before you lose your commit messages.
Vinnl 3y ago
The challenge is that it's hard to see the value of good commits if you've never done a `git blame` or `git bisect`, but you can't really use those until you have good commits. A bit of a chicken and egg problem.

j4yav 3y ago

I spent most of my career in ops, specifically packaging and deployment, and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie.

radiator 3y ago
For some codebases, if you are lucky, you can trust commit messages from specific trustworthy people. Diffs might not lie, but they take much more space and time to read than 'git log --oneline'.
tivert 3y ago
> ...and one of the most important things I learned early is to never trust commit messages. This has been just as true at places that spent an ungodly amount of time grooming their commit messages. It's pretty easy now to work with diffs directly, and diffs don't lie. That's a sentiment that's very easy to take too far, and shy people away from valuable commit message practices out of misplaced perfectionism. Diffs definitely can lie. Not about the way it is, but about the way it should be. Commit messages are insanely valuable, and often convey important information that's impossible or unreasonable to communicate in any other way (for instance, things like like intent and rationales). Diffs can say ABCD, commit messages can say CDEF. They all should be considered, together, but with a reasonable dose of skepticism, when you're figuring something out. Some things that are true (if you're system lives long enough): 1. There's a good chance your documentation wiki will get purged or severely corrupted in some migration before you lose your commit messages. 2. There's a good chance your ticket system will get purged or severely corrupted in some migration before you lose your commit messages.

Vinnl 3y ago

The challenge is that it's hard to see the value of good commits if you've never done a `git blame` or `git bisect`, but you can't really use those until you have good commits. A bit of a chicken and egg problem.