Rules for commit messages

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. Ideally less than 75 characters, but certainly not longer than 80. If the alterations pertain to a specific UI deliverable in Anaconda, begin the line with the lowercase name - gui, tui.

    Here are acceptable first lines for git commit messages:

    Fix bootloader configuration setup on ppc64
    gui: Introduce a new screen for setting your preferred email client
    
  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 or CentOS Stream bugs, all commits need to reference a bug issue name. These bugs can be filed here.

    If you have a patch that is Related to or Reverts another bug, you may add those line to the end of the long commit message in this format:

    Related: RHEL-ISSUENUMBER
    Reverts: RHEL-ISSUENUMBER
    Resolves: RHEL-ISSUENUMBER
    

    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.

    On RHEL branches, the ‘bumpver’ process will verify that each patch for the release references a RHEL issue. The scripts/makebumpver script will extract the bug issues 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/Reverts line to the RPM spec file changelog.