That all depends on what you do with the meta-data in the commits. For example, at my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.
Merge information is incredibly useful to developers (even if only to provide a smart "git bisect"). But would you generate a user-visible changelog from your merges? I personally wouldn't, and that's the point GP was making.
> But would you generate a user-visible changelog from your merges?
We can, and do. Knowing that the merges are going to wind up as items in the changelog leads us to size and structure them accordingly, or at least make a best effort to. The end result is a changelog where most PRs are somehow "noteworthy" and the ones that aren't (usually "chore" type in Conventional Commits lingo) can all be grouped together down the tail end.
The point isn't to produce a perfect result, but one that is "good enough". With this system, the friction to produce a new release is so low, and we have so many projects, that we can easily push out a steady stream of releases at very low cost with this approach. And following the pattern across all the projects has been great for consistency, compared to the relative chaos in patterns and procedures that we had before.
That all depends on what you do with the meta-data in the commits. For example, in my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.
Patch descriptions are for developers, not for users -- aside from the fact they're the wrong granularity (no user cares if it took 20 patches and three PR cycles to implement a feature), they should contain details and justification that are only useful for future debugging or for review purposes (which users also don't care about). And if you have a bugfix for a previously-merged patch that hasn't yet been released, why would you include the bugfix in the changelog?
Yes, with the right format and discipline you could generate reasonable changelogs from your commit logs -- but at that point it's so much easier to just keep a CHANGELOG.md.
In my experience its unlikely this will be complete or accurate on any project maintained by a team of more than a couple of people.
Common practice for a long time has been to include a ticket id in the commit and then use a script to pull all the ticket ids from the commits since the last release and pull the (user facing) release note info from ticketing system.
Of course you don't want commit messages going to users but you don't want to rely on handcrafted lists either. Particularly when a release as far as a customer is concerned is infrequent and contains changes from many repos.
Exactly. I can read commit messages myself, but there's a lot of stuff in there that's not relevant to me as a consumer - e.g. refactorings, cleanups, etc.