This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Dropping ChangeLogs
On Fri, 22 Dec 2017, Eric S. Raymond wrote:
> Janne Blomqvist <blomqvist.janne@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
joseph@codesourcery.com