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