6 ms·

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.

by 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.

6 ms·

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.

by j4yav 3y ago

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.