"Because log diffs are full of noise. Can we really expect every single commit in an open source project to be meaningful and self-explanatory? That seems like a pipe dream."
I thought this was the point of squashing your commits together when making a pull request, so the `git log` of master reads like a changelog. You can also interactively rebase and change commit messages if the wording is confusing.
The definition of "meaningful" might be a bit soft here. When figuring out what changed in a release, I don't really care that you "converted tabs to spaces" or "refactored method name based on intent" or any such structural change. The git log is generally too noisy to be used for describing a release.
Exactly: There are two very different use-cases and audiences.
Your version-control system should be helping programmers understand the evolution of the codebase, or the reasons behind certain line-changes... especially when those changes were made by someone else long ago.
The changelog, on the other hand, is for a less-technical (or at least less-involved) audience. It has to summarize the net-change which occurs in a way which is meaningful to people asking different sets of questions. Such as: "What are the new features?" and "Did they change anything about X?"
I thought this was the point of squashing your commits together when making a pull request, so the `git log` of master reads like a changelog. You can also interactively rebase and change commit messages if the wording is confusing.