diff options
author | David Cantrell <dcantrell@redhat.com> | 2010-04-09 09:41:18 -1000 |
---|---|---|
committer | David Cantrell <dcantrell@redhat.com> | 2010-04-12 09:23:07 -1000 |
commit | b5418e47ac37cf0b1a600c3932bde0fc4a7c71cb (patch) | |
tree | 3f797fce5df9c6d7a28e00b21fe7e741f0721ea5 /docs/commit-log.txt | |
parent | 4e868ac0fa6dcef776ec43298b13136c24aa0a65 (diff) | |
download | anaconda-b5418e47ac37cf0b1a600c3932bde0fc4a7c71cb.tar.gz anaconda-b5418e47ac37cf0b1a600c3932bde0fc4a7c71cb.tar.xz anaconda-b5418e47ac37cf0b1a600c3932bde0fc4a7c71cb.zip |
Add docs/commit-log.txt explaining git commit log policies.
Mostly for RHEL bug number referencing, but some rules to follow to make
sure commit log messages are consistent.
Diffstat (limited to 'docs/commit-log.txt')
-rw-r--r-- | docs/commit-log.txt | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/docs/commit-log.txt b/docs/commit-log.txt new file mode 100644 index 000000000..7671f7104 --- /dev/null +++ b/docs/commit-log.txt @@ -0,0 +1,58 @@ +git commit messages for anaconda should follow a consistent format. The +following are rules to follow when committing a change to the git repo: + +1) The first line of the commit message should be a short summary of the + change in the patch. We also place (#BUGNUMBER) at the end of this + line to indicate the bugzilla.redhat.com bug number addressed in this + patch. The bug number is optional since there may be no bug number, + but if you have one you are addressing, please include it on the + summary line. Lastly, the summary lines need to be short. Ideally + less than 75 characters, but certainly not longer than 80. + + Here are acceptable first lines for git commit messages: + + Check partition and filesystem type on upgrade (#123456) + Fix bootloader configuration setup on ppc64 (#987654) + Introduce a new screen for setting your preferred email client + + The last one would be a new feature that we didn't have a bug number + for. + +2) The main body of the commit message should begin TWO LINES below the + summary line you just entered (that is, there needs to be a blank line + between the one line summary and the start of the long commit message). + Please document the change and explain the patch here. Use multiple + paragraphs and keep the lines < 75 chars. DO NOT indent these lines. + Everything in the git commit message should be left justified. PLEASE + wrap long lines. If you don't, the 'git log' output ends up looking + stupid on 80 column terminals. + +3) For RHEL bugs, all commits need to reference a bug number. You may + follow one of two formats for specifying the bug number in a RHEL commit. + + a) Put the bug number on the summary line in (#BUGNUMBER) format. Bugs + listed this way are treated as 'Resolves' patches in the RHEL + universe. + + b) If you have a patch that is Related to or Conflicts with another bug, + you may add those lines to the end of the long commit message in this + format: + + Related: rhbz#BUGNUMBER + Conflicts: rhbz#BUGNUMBER + Resolves: rhbz#BUGNUMBER + + These entries should come at the end of the long commit message and + must follow the format above. You may have as many of these lines as + appropriate for the patch. + + c) Patches that are 'Resolves' patches have two methods to specify the + bug numbers, but Related and Conflicts can only be listed in the long + commit message. + + On RHEL branches, the 'bumpver' process will verify that each patch for + the release references a RHEL bug number. The scripts/makebumpver script + will extract the bug numbers from RHEL branch commits and do two things. + First, it verifies that the bug referenced is a RHEL bug and in correct + states. Second, it adds the appropriate Resolves/Related/Conflicts line + to the RPM spec file changelog. |