I can concur it can be senseless with 1:1 mapping between commits and the logs.
However neither is that true, not have the git commit messages been kept up to date, nor has there been an easily interpretable log of what changes have been made.
I would propose changelog can be mutable (if you keep working on a change, update it over time). Or we can keep a differently formed log of changes. Git messages are inappropriate, in my opinion, because they are about tracking individual chunks of changes ("tactics"), not the larger change ("strategy"). Think: "there should be a cover message for commits", as is the case with mailing list based review and merge approach. Pull request model is a possible way out, but requires everyone to consistently adopt it; the message ends up in there as a merge commit, editable at the time of the merge, which is nice.
But either there's more sensible logging of changes over time, or we do away with announcing changes in a release that happens yearly. Because as is, it's too much for a person to spend an afternoon being effectively a journalist of code archaeology.
Is this a fix? Is this a security fix? Is this just a part of a security fix? Or is this a new feature? Or is this a portion of a new feature? Has this skeleton implementation been finished before this release -- how do we announce the work done? "Implemented" or "stubbed out"?
Either everyone please agree to keep a journal in ChangeLog file, or another change log; or consistently write about large chunks of code you wrote (e.g. NSOrderedSet as one entry of 3 sentences rather than 30 commits without anything related among them) so we can put them in release notes.
But whoever is cutting the next release (likely me, I'm ok doing it) should not have to understand and sift through one sentence commits that describe what was done, but neither why nor on what. Treat git commits as isolated, or treat merge commits as a unit of work, or write some descriptive log, or elect not to announce changes.
Those are the options.