This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: git commit message conventions
- From: Rich Felker <dalias at libc dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 2 Jun 2015 23:08:03 -0400
- 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>
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. I would strongly prefer to
see their use phased out.
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.
Rich