@@ -127,82 +127,82 @@ to add the upgraded version.
$ git commit -sa
- - The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
- to your commit message. There is the same requirement for contributing
- to the Linux kernel. Adding such a line signifies that you, the
- submitter, have agreed to the `Developer's Certificate of Origin 1.1
- <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
- as follows:
+ #. The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
+ to your commit message. There is the same requirement for contributing
+ to the Linux kernel. Adding such a line signifies that you, the
+ submitter, have agreed to the `Developer's Certificate of Origin 1.1
+ <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
+ as follows:
- .. code-block:: none
+ .. code-block:: none
- Developer's Certificate of Origin 1.1
+ Developer's Certificate of Origin 1.1
- By making a contribution to this project, I certify that:
+ By making a contribution to this project, I certify that:
- (a) The contribution was created in whole or in part by me and I
- have the right to submit it under the open source license
- indicated in the file; or
+ (a) The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license
+ indicated in the file; or
- (b) The contribution is based upon previous work that, to the best
- of my knowledge, is covered under an appropriate open source
- license and I have the right under that license to submit that
- work with modifications, whether created in whole or in part
- by me, under the same open source license (unless I am
- permitted to submit under a different license), as indicated
- in the file; or
+ (b) The contribution is based upon previous work that, to the best
+ of my knowledge, is covered under an appropriate open source
+ license and I have the right under that license to submit that
+ work with modifications, whether created in whole or in part
+ by me, under the same open source license (unless I am
+ permitted to submit under a different license), as indicated
+ in the file; or
- (c) The contribution was provided directly to me by some other
- person who certified (a), (b) or (c) and I have not modified
- it.
+ (c) The contribution was provided directly to me by some other
+ person who certified (a), (b) or (c) and I have not modified
+ it.
- (d) I understand and agree that this project and the contribution
- are public and that a record of the contribution (including all
- personal information I submit with it, including my sign-off) is
- maintained indefinitely and may be redistributed consistent with
- this project or the open source license(s) involved.
+ (d) I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
- - Provide a single-line summary of the change and, if more
- explanation is needed, provide more detail in the description of the
- commit. This summary is typically viewable in the "shortlist" of
- changes. Thus, providing something short and descriptive that
- gives the reader a summary of the change is useful when viewing a
- list of many commits. You should prefix this short description
- with the recipe name (if changing a recipe), or else with the
- short form path to the file being changed.
+ #. Provide a single-line summary of the change and, if more
+ explanation is needed, provide more detail in the description of the
+ commit. This summary is typically viewable in the "shortlist" of
+ changes. Thus, providing something short and descriptive that
+ gives the reader a summary of the change is useful when viewing a
+ list of many commits. You should prefix this short description
+ with the recipe name (if changing a recipe), or else with the
+ short form path to the file being changed.
- .. note::
+ .. note::
- To find a suitable prefix for the commit summary, a good idea
- is to look for prefixes used in previous commits touching the
- same files or directories::
+ To find a suitable prefix for the commit summary, a good idea
+ is to look for prefixes used in previous commits touching the
+ same files or directories::
- git log --oneline <paths>
+ git log --oneline <paths>
- - For the commit description, provide detailed information
- that describes what you changed, why you made the change, and the
- approach you used. It might also be helpful if you mention how you
- tested the change. Provide as much detail as you can in the commit
- description.
+ #. For the commit description, provide detailed information
+ that describes what you changed, why you made the change, and the
+ approach you used. It might also be helpful if you mention how you
+ tested the change. Provide as much detail as you can in the commit
+ description.
- .. note::
+ .. note::
- If the single line summary is enough to describe a simple
- change, the commit description can be left empty.
+ If the single line summary is enough to describe a simple
+ change, the commit description can be left empty.
- - If the change addresses a specific bug or issue that is associated
- with a bug-tracking ID, include a reference to that ID in the body of the
- commit message. For example, the Yocto Project uses a
- specific convention for bug references --- any commit that addresses
- a specific bug should use the following form for the body of the commit
- message. Be sure to use the actual bug-tracking ID from
- Bugzilla for bug-id::
+ #. If the change addresses a specific bug or issue that is associated
+ with a bug-tracking ID, include a reference to that ID in the body of the
+ commit message. For example, the Yocto Project uses a
+ specific convention for bug references --- any commit that addresses
+ a specific bug should use the following form for the body of the commit
+ message. Be sure to use the actual bug-tracking ID from
+ Bugzilla for bug-id::
- single-line summary of change
+ single-line summary of change
- Fixes [YOCTO #bug-id]
+ Fixes [YOCTO #bug-id]
- detailed description of change
+ detailed description of change
#. *Crediting contributors:* By using the ``git commit --amend`` command,
you can add some tags to the commit description to credit other contributors