Closes #4275. --- eng/vc-users.rst | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 71 insertions(+), 6 deletions(-)
diff --git a/eng/vc-users.rst b/eng/vc-users.rst index 31de516..5d2dfb4 100644 --- a/eng/vc-users.rst +++ b/eng/vc-users.rst @@ -422,20 +422,85 @@ then you rewrite those commits with ``git rebase`` and push them up again, the others will have to re-merge their work and trying to integrate their work into yours can become messy. -Accessing a developer's repository +Accessing a Developer's Repository ---------------------------------- RTEMS developers with Git commit access have personal repositories on https://git.rtems.org/ that can be cloned to view cutting-edge development work shared there. +Commit Message Guidance +----------------------- + +The commit message associated with a change to any software project +is of critical importance. It is the explanation of the change and the +rationale for it. Future users looing back through the project history +will rely on it. Even the author of the change will likely rely on it +once they have forgotten the details of the change. It is important to +make the message useful. Here are some guidelines followed by the RTEMS +Project to help improve the quality of our commit messages. + +* When committing a change the first line is a summary. Please make it short + while hinting at the nature of the change. You can discuses the change + if you wish in a ticket that has a PR number which can be referenced in + the commit message. After the first line, leave an empty line and add + whatever required details you feel are needed. + +* Format the commit message so it is readable and clear. If you have + specific points related to the change make them with separate paragraphs + and if you wish you can optionally uses a `-` marker with suitable + indents and alignment to aid readability. + +* Limit the line length to less than 80 characters + +* Please use a real name with a valid email address. Please do not use + pseudonyms or provide anonymous contributions. + +* Please do not use terms such as "Fix bug", "With this change it + works", or "Bump hash". If you fix a bug please state the nature of the + bug and why this change fixes it. If a change makes something work then + detail the reason. You do not need to explain the change line by line + as the commits diff and associated ticket will. + +* If you change the formatting of source code in a repository please + make that a separate patch and use "Formatting changes only" on the first + line. Please indicate the reason or process. For example to "Conforming + to code standing", "Reverting to upstream format", "Result of automatic + formatting". + +* Similarly, if addressing a spelling, grammar, or Doxygen issue, please + put that in a commit by itself separate from technical changes. + +An example commit message: + +.. code-block:: shell + + test/change: Test message on formatting of commits + + - Shows a simple single first line + + - Has an empty second line + + - Shows the specifics of adding separate points in the commit message as + separate paragraphs. It also shows a `-` separator and multilines + that are less than the 80 character width + + - Show a ticket update and close + + Updates #9876 + Closes #8765 + +The first line generally starts with a file or directory name which +indicates the area in RTEMS to which the commit applies. For a patch +series which impacts multiple BSPs, it is common to put each BSP into +a separate patch. This improves the quality and specificity of the +commit messages. + Creating a Patch ----------------- +----------------- -Before submitting a patch read about `Contributing -<https://devel.rtems.org/wiki/Developer/Contributing>`_ to RTEMS and the -`Commit Message <https://devel.rtems.org/wiki/Developer/Git#GitCommits>`_ -formatting we require. +Before submitting a patch, please read `Commit Message Guidance`_ to +become familiar with the commit message formatting we require. The recommended way to create a patch is to branch the Git repository master and use one commit for each logical change. Then you can use -- 1.8.3.1 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
