@@ -137,8 +137,8 @@ notes about [commit squashing](#commit-squashing)).
|
137 | 137 | A good commit message should describe what changed and why. |
138 | 138 | |
139 | 139 | 1. The first line should: |
140 | | -- contain a short description of the change (preferably 50 characters or less, |
141 | | - and no more than 72 characters) |
| 140 | +- contain a short description of the change (preferably 50 characters or |
| 141 | +less, and no more than 72 characters) |
142 | 142 | - be entirely in lowercase with the exception of proper nouns, acronyms, and |
143 | 143 | the words that refer to code, like function/variable names |
144 | 144 | - be prefixed with the name of the changed subsystem and start with an |
@@ -456,7 +456,8 @@ Focus first on the most significant aspects of the change:
|
456 | 456 | 1. Does this change make sense for Node.js? |
457 | 457 | 2. Does this change make Node.js better, even if only incrementally? |
458 | 458 | 3. Are there clear bugs or larger scale issues that need attending to? |
459 | | -4. Is the commit message readable and correct? If it contains a breaking change is it clear enough? |
| 459 | +4. Is the commit message readable and correct? If it contains a breaking change |
| 460 | + is it clear enough? |
460 | 461 | |
461 | 462 | When changes are necessary, *request* them, do not *demand* them, and do not |
462 | 463 | assume that the submitter already knows how to add a test or run a benchmark. |
|