diff options
author | Quentin Schulz <quentin.schulz@cherry.de> | 2025-09-18 12:24:43 +0200 |
---|---|---|
committer | Steve Sakoman <steve@sakoman.com> | 2025-09-30 08:01:59 -0700 |
commit | 1b7cb8a80c297e7bce9e27bbfbf40f5da50ec39f (patch) | |
tree | 7cd6d65bed5353a5bf8f664d3a6ce6db0dd81b08 | |
parent | afd75083e90c9e2318f2c9a61635fde47839dcb0 (diff) | |
download | poky-1b7cb8a80c297e7bce9e27bbfbf40f5da50ec39f.tar.gz |
contributor-guide: submit-changes: reword commit message instructions
This should hopefully make it clearer what is expected from the
contributor.
This follows my understanding of git-commit(1)[1] where the following is
a git commit message:
"""
git commit title
git commit description
"""
I'm putting the "Fixes [YOCTO" line in "body of the commit message" so
it's understood as being different from the git commit description so
that the note admonition allowing us to have an empty commit description
doesn't apply to the "Fixes [YOCTO" line.
[1] https://www.man7.org/linux/man-pages/man1/git-commit.1.html#DISCUSSION
(From yocto-docs rev: f0f9d40a04cba684a476caaa053b6f24ade9fb99)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit b84903a760350bd118c56ea9ce4e98039edf6e55)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
-rw-r--r-- | documentation/contributor-guide/submit-changes.rst | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index f77dc91467..754c727aad 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst | |||
@@ -163,7 +163,7 @@ to add the upgraded version. | |||
163 | this project or the open source license(s) involved. | 163 | this project or the open source license(s) involved. |
164 | 164 | ||
165 | - Provide a single-line summary of the change and, if more | 165 | - Provide a single-line summary of the change and, if more |
166 | explanation is needed, provide more detail in the body of the | 166 | explanation is needed, provide more detail in the description of the |
167 | commit. This summary is typically viewable in the "shortlist" of | 167 | commit. This summary is typically viewable in the "shortlist" of |
168 | changes. Thus, providing something short and descriptive that | 168 | changes. Thus, providing something short and descriptive that |
169 | gives the reader a summary of the change is useful when viewing a | 169 | gives the reader a summary of the change is useful when viewing a |
@@ -179,23 +179,23 @@ to add the upgraded version. | |||
179 | 179 | ||
180 | git log --oneline <paths> | 180 | git log --oneline <paths> |
181 | 181 | ||
182 | - For the body of the commit message, provide detailed information | 182 | - For the commit description, provide detailed information |
183 | that describes what you changed, why you made the change, and the | 183 | that describes what you changed, why you made the change, and the |
184 | approach you used. It might also be helpful if you mention how you | 184 | approach you used. It might also be helpful if you mention how you |
185 | tested the change. Provide as much detail as you can in the body | 185 | tested the change. Provide as much detail as you can in the commit |
186 | of the commit message. | 186 | description. |
187 | 187 | ||
188 | .. note:: | 188 | .. note:: |
189 | 189 | ||
190 | If the single line summary is enough to describe a simple | 190 | If the single line summary is enough to describe a simple |
191 | change, the body of the commit message can be left empty. | 191 | change, the commit description can be left empty. |
192 | 192 | ||
193 | - If the change addresses a specific bug or issue that is associated | 193 | - If the change addresses a specific bug or issue that is associated |
194 | with a bug-tracking ID, include a reference to that ID in your | 194 | with a bug-tracking ID, include a reference to that ID in the body of the |
195 | detailed description. For example, the Yocto Project uses a | 195 | commit message. For example, the Yocto Project uses a |
196 | specific convention for bug references --- any commit that addresses | 196 | specific convention for bug references --- any commit that addresses |
197 | a specific bug should use the following form for the detailed | 197 | a specific bug should use the following form for the body of the commit |
198 | description. Be sure to use the actual bug-tracking ID from | 198 | message. Be sure to use the actual bug-tracking ID from |
199 | Bugzilla for bug-id:: | 199 | Bugzilla for bug-id:: |
200 | 200 | ||
201 | single-line summary of change | 201 | single-line summary of change |