diff options
author | Alex Meade <alex.meade@rackspace.com> | 2013-04-26 15:25:17 -0400 |
---|---|---|
committer | Alex Meade <alex.meade@rackspace.com> | 2013-04-26 15:26:14 -0400 |
commit | e750e9b0ed7de080f72060844e0cbc2911aa682a (patch) | |
tree | 7128e66d61f482d5cbcfb7dd9f80d43751d2033c /HACKING.rst | |
parent | addd3c3be383d9db363415096d5dcc4fe384af97 (diff) | |
download | python-glanceclient-e750e9b0ed7de080f72060844e0cbc2911aa682a.tar.gz |
Expand HACKING with commit message guidelines
Add a 'Commit Messages' section to HACKING describing how a commit
message should be formed.
Change-Id: Ife0d6eab18cc0f07ad8e8c79cb2e4198513236d2
Diffstat (limited to 'HACKING.rst')
-rw-r--r-- | HACKING.rst | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/HACKING.rst b/HACKING.rst index b6494bb..29b9e33 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -184,3 +184,32 @@ For every new feature, unit tests should be created that both test and bug that had no unit test, a new passing unit test should be added. If a submitted bug fix does have a unit test, be sure to add a new one that fails without the patch and passes with the patch. + + +Commit Messages +--------------- +Using a common format for commit messages will help keep our git history +readable. Follow these guidelines: + + First, provide a brief summary of 50 characters or less. Summaries + of greater then 72 characters will be rejected by the gate. + + The first line of the commit message should provide an accurate + description of the change, not just a reference to a bug or + blueprint. It must be followed by a single blank line. + + Following your brief summary, provide a more detailed description of + the patch, manually wrapping the text at 72 characters. This + description should provide enough detail that one does not have to + refer to external resources to determine its high-level functionality. + + Once you use 'git review', two lines will be appended to the commit + message: a blank line followed by a 'Change-Id'. This is important + to correlate this commit with a specific review in Gerrit, and it + should not be modified. + +For further information on constructing high quality commit messages, +and how to split up commits into a series of changes, consult the +project wiki: + + http://wiki.openstack.org/GitCommitMessages |