git commit's -v or --verbose flag allows you to see a diff of your currently staged changes so that sounds somewhat similar to your command. I find that seeing

git commit's -v or --verbose flag allows you to see a diff of your currently staged changes so that sounds somewhat similar to your command. I find that seeing the exact changes you're about to commit does lead to more detailed git commit messages, although the maximum length of most "properly" written commit message titles (50 characters) tends to hinder the quality of commit message titles as entries in a changelog. They're often very high level summaries of introduced changes and it's common for people to focus on the change at hand — not on its impact on end-users — when writing a commit. Again, this all goes back to the intended audience for commit messages compared to change logs. If the end users of the projects you work on diligently read every commit in the project history, then I dare suggest you're in a rare and privileged situation. I don't expect end-users of most open source software to be satisfied with either the high-level nature of commit titles, or their minutia. This leads me to think that keepachangelog.com needs to gather more examples of the of changelogs I advocate for. It seems that a surprisingly small number of people have encountered them. Rebasing and squashing commits to clean them up to be changelog-worthy does not solve the 50-character issue with conventional commit titles I mentioned above. It also doesn't solve for situations with collaborative pull requests or branches. That is, unless there's a clear process for squashing and rebasing being done by a single person at the very end of the project. I think it's more realistic to expect a single file changelog to be regularly updated (through an Unrealeased section) as changesets are being introduced prior to a release and to eventually update this same single file when the group of changesets is about to be released under a new dated version release.