On Fri, 22 Dec 2017, Eric S. Raymond wrote: > Janne Blomqvist <blomqvist.ja...@gmail.com>: > > My secret desire is that once we get this done we would drop these > > silly ChangeLogs. Although I'm not a kernel developer, I kind of like > > the Linux kernel style, where the commit msg contains a reasonably > > in-depth motivation for the change, sort of like the email message one > > sends to gcc-patches when introducing a patch (in fact, if one uses > > git format-patch + git send-email this kind of workflow is supported > > out-of-the-box). I find that a lot more useful than a screenful of > > "Likewise". YMMV. > > I strongly endorse this position. > > Janne is correct to point out that git is designed to be used in a > patch-centric workflow with a specific style of commenting - summary > line, plus optional separator and running text. This is expressed > especially in the UI design of git log and gitk. > > ChangeLogs are a relic from the days before version-control systems with > real changesets. When you have real changesets, all ChangeLogs do is > add unnecessary process friction.
I proposed removing the GNU Coding Standards requirement for ChangeLog format when using a public distributed VCS with per-logical-changeset commits in <https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00000.html> (discussion continues in August, September, November). However, each time the discussion has tailed off without reaching a conclusion from RMS to remove the requirement, or a conclusion that it should not be removed. (The use of ChangeLog *files*, as opposed to the *format*, is a peripheral matter - the GNU Coding Standards already allow generating such files for release tarballs from appropriately-formatted commit messages rather than needing to check in ChangeLog files, but it's the format that forces a focus on a particular level of detail that duplicates the information available from the patches themselves in the VCS. Thus, whether something generated from commit logs is required to be in release tarballs when not using ChangeLog format is also a peripheral matter. GCC already has a complicated script for release (and snapshot) tarball generation, which we'll need to update for moving to git. glibc just uses "git archive", but if some form of log were required in release tarballs it would always be possible to have a step in the (long) release checklist of generating and checking in such a file right before tagging the release, and so still to use "git archive".) I have used git-style commit messages (with the ChangeLog content at the end) in GCC for some time. -- Joseph S. Myers jos...@codesourcery.com
