From be1c5b574b91b55762c76ee7e042ada6ee81e3a4 Mon Sep 17 00:00:00 2001 From: Andrei Rybak Date: Sat, 14 Jan 2023 14:24:43 +0100 Subject: [PATCH] CONTRIBUTING.md: use block syntax for prose examples Use Markdown block syntax for the example of a commit message instead of hard-line breaks with double spaces at the end. Such formatting separates it from the other parts of the text in `CONTRIBUTING.md` and makes the wrapping at 74 characters easier to understand with monospace font. Do the same to the examples of `CHANGELOG.md` entries. Signed-off-by: Andrei Rybak --- CONTRIBUTING.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e752c5801..c2bdbce54 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -39,19 +39,19 @@ See: [Signed-off-by Lines][8] Also, please write good git commit messages. A good commit message looks like this: -Header line: explaining the commit in one line - -Body of commit message is a few lines of text, explaining things -in more detail, possibly giving some background about the issue -being fixed, etc etc. - -The body of the commit message can be several paragraphs, and -please do proper word-wrap and keep columns shorter than about -74 characters or so. That way "git log" will show things -nicely even when it's indented. - -Reported-by: whoever-reported-it -Signed-off-by: Your Name \ + Header line: explaining the commit in one line + + Body of commit message is a few lines of text, explaining things + in more detail, possibly giving some background about the issue + being fixed, etc etc. + + The body of the commit message can be several paragraphs, and + please do proper word-wrap and keep columns shorter than about + 74 characters or so. That way "git log" will show things + nicely even when it's indented. + + Reported-by: whoever-reported-it + Signed-off-by: Your Name That header line really should be meaningful, and really should be just one line. The header line is what is shown by tools like gitk and shortlog, and should summarize the change in one readable line of text, independently of the longer explanation. @@ -64,11 +64,11 @@ Example with gitk Additionally when important changes to behaviors, fixes or new feature are introduced an entry must be added to CHANGELOG.md file. Always add new entries at the very top of the file above other existing entries. Use this layout for new entries: -Area: Details about the change [reference thread / issue] + Area: Details about the change [reference thread / issue] When multiple areas are affected list the areas separated with a /: -Area1/Area2: Detail about the change [reference thread / issue] + Area1/Area2: Detail about the change [reference thread / issue] Here is a (non exhaustive) list of Areas that can be used: * Bluetooth