3 ms·
How do you test that the commit messages are accurate over time for what the software does? Anytime Ive done code archaeology, the commit messages, no matter h
by 8note 4y ago
How do you test that the commit messages are accurate over time for what the software does?
Anytime Ive done code archaeology, the commit messages, no matter how detailed, have been irrelevant to what's currently running.
Between reading a book of commit comments, or the authoritative code, it's much more efficient to just read the code.
One of the big things with commit messages is that they won't capture changes in adjacent systems that don't share a code base. While you can spot weird edge cases in the code, you can't from the commit messages alone
- peterkelly 4y agoOh, they don't remain accurate over time. The point is to capture what is true at the time the commit is made, and in aggregate to tell a story of the code's evolution. If someone wants to know why a particular thing is done the way it is, then this can provide insights as to how it got that way and why. I don't regard a commit log as an adequate substitute for documentation on the latest version of a codebase. Rather, it can provide a useful starting point for writing documentation that I find easier than beginning from a "blank page" so to speak. It's a starting point only - there's a lot of work required to get from that point to an accurate description of the most recent version of a codebase. I agree with your point about changes in adjacent systems, though where that happens I try to mention those changes in the commit message and explain how they relate to the commit itself. I'm speaking mostly from experience working on software that exists in a single repository; for things that are split among multiple independent repositories/services I agree it's more difficult (and this is why i prefer monorepos whenever its viable).