This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: git commit message conventions
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Wed, 03 Jun 2015 08:59:31 +0200
- Subject: Re: git commit message conventions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1506022041430 dot 2704 at digraph dot polyomino dot org dot uk> <556E563C dot 1090204 at cs dot ucla dot edu> <20150603030803 dot GL17573 at brightrain dot aerifal dot cx>
On Tue, 2015-06-02 at 23:08 -0400, Rich Felker wrote:
> On Tue, Jun 02, 2015 at 06:19:56PM -0700, Paul Eggert wrote:
> > Joseph Myers wrote:
> > >I propose that we adopt standard git commit message conventions that: the
> > >first line of a commit message is a short description of the commit, the
> > >next line is a blank line, and the rest of the commit message is the
> > >detailed description / rationale for the patch
> >
> > Many other GNU projects use this style, but with one further
> > constraint: if you indent the entire commit message, and omit the
> > 2nd (empty) line, the entire commit message must be a valid
> > ChangeLog entry. That way, there's a one-to-one relationship
> > between commit messages and ChangeLog entries, and programs like
> > vc-dwim can be used to generate commits. Projects that use such a
> > style include Coreutils, Gnulib, and GNU Emacs. I suggest using it
> > for glibc as well.
>
> I find the GNU style changelog messages utterly worthless. They
> describe the "where" and to some minimal extent the "what" of a change
> set, but this is all information which is maintained automatically by
> any sane version control system such a git.
The "what" is a condensed version of the actual patch content, so it
provides some benefit to those who want to have a summary of the "what"
without having to look at the full patch.
Some of this information might be part of the commit messages as
proposed by Joseph, but in a less structured way and it's not automatic.
> I really like Joseph Myers' proposal for glibc, which I think is
> basically the same as the commit policy I've imposed in musl and which
> I've been encouraging other projects to adopt.
I do like it too; Changelog is a separate topic though, I believe.