Mostly for RHEL bug number referencing, but some rules to follow to make sure commit log messages are consistent. --- docs/commit-log.txt | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 58 insertions(+), 0 deletions(-) create mode 100644 docs/commit-log.txt diff --git a/docs/commit-log.txt b/docs/commit-log.txt new file mode 100644 index 0000000..7671f71 --- /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. -- 1.6.6.1 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
