Simon Josefsson wrote: > - gitlog-to-changelog produces nice outputs when the GNU changelog > pattern is used in git commit messages, but I found that git2cl > produces better looking outputs for projects that uses more terse > one-line git commit messages. Git2cl automatically lists the relevant > files, wheras gitlog-to-changelog relies on the git commit author to > have done this in the commit message. > > I still occasionaly maintain git2cl, but I have migrated almost all my > projects from git2cl to gitlog-to-changelog > ... > I think it is better if most people reach for gitlog-to-changelog.
Thanks for the very fair answer. > I'm not sure what the future for ChangeLog files in tarballs is: for > many realistic and practical purposes, I think 'git log' is better. Sure. The point is that tarballs are made for users who don't have special tools installed (bison, doxygen, texlive, etc.) and don't contain the git history. > One problem with both git2cl and gitlog-to-changelog is that you need > the full git history to produce the same output. A sparse or partial > git clone results in different output. So you cannot re-create the > 'make dist' tarball from a sparse git checkout Why is that a problem? The developers who run "make dist" do have the disk space and network bandwidth to do a "git clone" first. > , which I think is problematic from a supply-chain security perspective. huh? Who in the supply chain is relying on doing "make dist" after "git clone --depth 1" ? "make dist" from a tarball ought to work, though (I think Automake's 'distcheck' target verifies that). > I think the GNU ChangeLog format as a documentation convention is still > very much useful, and the document could be rewritte into a > "git-log-commit-message convention". I agree. > There was a good somewhat related > discussion in the Guix community recently (subject 'Revisiting the > "ChangeLog" style.') https://lists.gnu.org/archive/html/guix-devel/2025-07/threads.html#00027 Bruno
