git commit message conventions
Joseph Myers
joseph@codesourcery.com
Thu Jun 4 15:18:00 GMT 2015
On Wed, 3 Jun 2015, Ondøej BĂlka wrote:
> Correct, I just use script to add bug in NEWS and open bugzilla window so that
> isn't as much problem. Changelogs are likewise generated most of time, I
> dont have script to extract it from mail, does anybody have one?
> As far as I recall discussion only Roland found changelogs useful,
> otherwise it was inertia.
I find ChangeLog messages are useful in some cases as a table of contents
to the patch, for those patches where a ChangeLog entry relates
meaningfully to the level at which the patch operates (not for a global
change across many files, not for a change rearranging things so a
description in terms of individual named entities is at the wrong level to
describe the rearrangement).
I don't think it's particularly useful to have separate ChangeLogs for
localedata and libidn. I think it would be fine to have a system that
generates ChangeLogs for release tarballs from git logs (of course this
would mean "git archive" could no longer be used), provided it supports
multi-author changes and corrections to the logs (including author and
date) for past changes, even if it doesn't support putting things in three
separate ChangeLogs. (We'd also need to work out how it should handle
merges, though we generally discourage merge commits on master for most
trivial merge cases.)
I think it would be fine to have a system to extract the list of fixed
bugs from Bugzilla at release time (I'm supposing someone would run a
script and then put the list in NEWS manually and check in the change,
with subsequent corrections to that list being done manually as well),
which would need a convention for how you record the fixed version /
versions in Bugzilla in a searchable way and people watching that this
gets set when marking bugs fixed.
But my present proposal is for a more limited incremental change: don't
use a single-line commit message with a more substantial write-up in the
libc-alpha email, put the libc-alpha email contents in the commit message
instead. If you wish to format your commit message so it has a more
fully-defined relation to the ChangeLog entry, that's entirely fine by my
proposal, just not required.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list