It sounds like you're confusing what the author is describing with GNU "Change Logs" (https://www.gnu.org/prep/standards/html_node/Change-Logs.htm...), which track every source file change and are indeed redundant with `git log` (or any other version control system record).
> Because log diffs are full of noise — by nature. They could not make a suitable change log even in a hypothetical project run by perfect humans who never make typos, never forget to commit new files, never miss any part of a refactoring. The purpose of a commit is to document one atomic step in the process by which the code evolves from one state to another. The purpose of a change log is to document the noteworthy differences between these states.
> As is the difference between good comments and the code itself, so is the difference between a change log and the commit log: one describes the why, the other the how.
I tend to agree with both of these comments, that git commits are a very acceptable (and actionable change log) and that git log diffs are full of noise. That doesn't invalidate them as change logs though.
I've got a command that will add everything that has changed in a directory tree except for ignored files, into a commit. And it is very helpful to write in the commit exactly what you're doing . You do this once a day and you've got an excellent log not only of how you have changed things but you can hop back to a previous commit and reset to a previous day.
Now when it comes time to create a pull request ...
Then you can go back and rebase and squash from the original start, and things into a commit history that is explainable and readable for the project. The only thing that would make this even more seamless if you could do a split-squash where you take a commit, "ungroup" it into its individual changes, then put the changes into their respective commits, and then squash those with the commits for what something should be at the end point.
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.
> 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.
In my experience, they aren't. They want a top-level view of why/if they should upgrade.
In my dayjob, when preparing a release, we use tools to dump the git commit messages into the head of the CHANGELOG, then edit it back into user-facing text. We omit changes that are not user-facing (eg. 'gem you've never heard of upgraded to 0.4.4') and focus on changes they care about (eg. 'Redact credentials from URLs in a cached buildpack's output'). See for example our Ruby buildpack CHANGELOG[0].
We build our own binaries for buildpacks. So in addition, for our Github releases, we take the CHANGELOG entry and append a table of supported binaries and default versions[1]. These show up in the CHANGELOG only if we add or drop a core binary.
We work out of Tracker, so we link to Tracker stories, bugs and chores for every mentioned in the CHANGELOG or release notes.
If everyone else means "release notes" when they say "change log", why do the revision systems use the word "log" to refer to detailed revision change messages, I wonder. For instance the RCS $Log$ expansion keyword, not only "git log".
What is a "git log diff"? I get"
$ git log diff
fatal: ambiguous argument 'diff': unknown revision or path not in the working tree.
I'm using the following format for commit messages:
Topic subject line, short exec. summary.
Optional: one or more paragraphs discussing the
"why", or any background information, how the
issue was found, why it's significant, how it
relates to something else, or what other changes
is this change a preparation for and so on.
* file1 (function1): This was done.
(function2) That. Typical ChangeLog stuff.
* file2 (function3): Bugfix here, and so on.
There a many valid places to use the word 'log'. Anything that you want to note can go in some kind of a log. A change log is a log of changes. Your users will want to see the changes that are relevant to them, and they vastly outnumber the developers who want to see a commit log.
Code may be read more than it is written, but it is not read far more than either. You really should have both logs: one detailed for development, and one for your users.
I never wrote that end users should be presented with change logs; of course, you give them release notes.
Release notes are not logs. They omit changes, and present selected changes in a different order. As soon as you have two sets of release notes for two releases in one file, then it's becoming a log: a log which captures sequences of release notes. I agree of keeping such a thing rather than giving end users just the notes for the current release.
In any case, developers should not be required to deposit any blurbs into any file as they are committing, regardless of its purpose and style.
Do go ahead and produce release notes, and then keep them in the repository. Do not mix code changes with changes to the release notes file.
This is calling for more use of what GNU calls a "NEWS file" (https://www.gnu.org/prep/standards/html_node/NEWS-File.html), which is what virtually everybody else means when they say "changelog". Per the page itself:
> Why can’t people just use a git log diff?
> Because log diffs are full of noise — by nature. They could not make a suitable change log even in a hypothetical project run by perfect humans who never make typos, never forget to commit new files, never miss any part of a refactoring. The purpose of a commit is to document one atomic step in the process by which the code evolves from one state to another. The purpose of a change log is to document the noteworthy differences between these states.
> As is the difference between good comments and the code itself, so is the difference between a change log and the commit log: one describes the why, the other the how.