That is indeed a difficult problem. Integration testing and contract testing can help to avoid this, but one can never be 100% sure.

https://xkcd.com/1172/

Or LazyVim

https://lazyvim.org/

Nice, I hadn’t heard of that one yet!

Thanks for your feedback!

Some thoughts:

• You could configure your cliff.toml (generated with git-cliff --init) to ignore any commits that aren’t interesting to your users
• You could use “squash merge” to the prerelease/staging/development branch so that you can commit without worry, and then only have your PR titles follow conventional commits (if the change is interesting to your users)

I should probably add those to the blog.

But yeah, I get preferring to write manual tailored changelogs. Personally I am just a little neurotic about single source of truth and a huge Git nerd. And I know that at least in this job, my users are neurotic enough to prefer completeness.