On the other hand, it takes a lot of discipline to make the second branch useful at all. If you constantly make short commits with messages like "stuff", why bother keeping them in the repo at all? There's a ton of junk you don't need in the typical code review, and making it useful requires... Discipline.
Git log is not a changelog
11–20 of 92 posts
Re: Git log is not a changelog
#12According to the GNU coding standards, which have been used for decades for a large amount of the core software on a Linux system, what you should put in the changelog looks quite a lot like a good git commit log would look like[0]. And Linux currently uses the git log as the changelog, and IIRC had a similar format in the pre-git era.
> The changelog targets your users. It must answer questions like:
> "What cool new feature is in this version?"
> "Is this annoying bug fixed?"
> "Is it safe to upgrade, or do I need to adjust my code/workflow to this new version?"
To me, that sounds like what a lot of projects would call "release notes" or (per GNU) "NEWS file"[1], not the changelog.
[0] https://www.gnu.org/prep/standards/standards.html#Change-Log... [1] https://www.gnu.org/prep/standards/standards.html#NEWS-File
Re: Git log is not a changelog
#13use https://www.conventionalcommits.org/en/v1.0.0/ , it has extensions that can autogenerate a nice looking changelog.
Re: Git log is not a changelog
#14The changelog, on the other hand, answers the question “why does the customer care about these changes?” It could be the same reason as why the commit exists, but the question is different. If the customer doesn’t care, maybe it doesn’t even need an entry. Maybe why they care is slightly different than the reason the commit(s) exist.
This is why I advocate for a hand-updated CHANGELOG.md. It’s a very small amount of writing that forces developers to consider how their PRs will impact customers that an auto-generator will never be able to do well.
Re: Git log is not a changelog
#15For these folks, putting deliberate effort into change logs, release notes, and documentation feels wasteful.
My hunch is that this is due to a missing feedback loop: we are unlikely to get feedback about documentation, and more likely to get feedback on our project’s code.
My own writing improved after a past project had a strong feedback loop with my documentation’s intended audience. This has been so damn rare in my career, that it’s never surprising when I meet programmers who are uncomfortable with technical writing.
Re: Git log is not a changelog
#16A git log is not a change log, sure. But PRs can contain a lot of useful information.
Re: Git log is not a changelog
#17The purpose of a git commit message is to answer the question “why does this commit exist?” That is the principal question you should be answering when you type `git commit`. This is the question you will be asking yourself when you find that commit in `git blame` or if it shows up in `git bisect`. Try to help your future self out. The changelog, on the other hand, answers the question “why does the customer care abo…
This avoid merge hell on the CHANGELOG.md file.
Re: Git log is not a changelog
#18Or if you didn’t actually release something you thought you did.
Re: Git log is not a changelog
#19The purpose of a git commit message is to answer the question “why does this commit exist?” That is the principal question you should be answering when you type `git commit`. This is the question you will be asking yourself when you find that commit in `git blame` or if it shows up in `git bisect`. Try to help your future self out. The changelog, on the other hand, answers the question “why does the customer care abo…
Sometimes, my Git commits can be kind of verbose (and I'll occasionally put in smartass comments).
I wouldn't dream of mining my Git logs for CHANGELOG entries.
Actually, I hand-run many things that a lot of developers automate.
Part of it is because I have control issues...
Re: Git log is not a changelog
#20The purpose of a git commit message is to answer the question “why does this commit exist?” That is the principal question you should be answering when you type `git commit`. This is the question you will be asking yourself when you find that commit in `git blame` or if it shows up in `git bisect`. Try to help your future self out. The changelog, on the other hand, answers the question “why does the customer care abo…
We autogenerate our CHANGELOG.md extract from Changelog-[section] our git commit messages (Release Captain massages them if necessary), and have a GH bot which checks that you have a Changelog- note somewhere in your PR commits (can be Changelog-None: ....). This avoid merge hell on the CHANGELOG.md file.
Right, if you don't do something like this you can be in merge hell very quickly...