- First line is a capitalized, short (50 chars or less) summary,
- Please include the component for which the change is being made in the first line
- [Analyzer] short (50 chars or less) summary
- [dart2js] short (50 chars or less) summary
- [CFE] short (50 chars or less) summary
- [CoreLib] short (50 chars or less) summary
- [ddc] short (50 chars or less) summary
- [VM - Runtime] short (50 chars or less) summary
Always add a blank line before more information. Many git tools assume this layout.
- More detailed explanatory text, if necessary. Wrap it to about 72 characters or so.
- When linking to an associated GitHub Issue
- DO NOT put
Issue 234 in the title
- DO Use the full GitHub URL to the issue - this ensures that the issue is clickable in Gerrit
- DO Use GitHub notation to auto-close bugs on commit
- If you don't want to delete the
BUG= boiler plate, at least add a space after the =. This ensures that the issue link is clickable in Gerrit.
- Write your commit message in the present tense: "Fix bug" and not "Fixed bug." This convention matches up with commit messages generated by commands like git merge and git revert.
Example
[VM - GC] Summarize changes in 50 chars or less
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some
contexts, the first line is treated as the subject of an email and the rest of the text as the
body. The blank line separating the summary from the body is critical (unless you omit the
body entirely); tools like rebase can get confused if you run the two together.
Closes https://github.com/dart-lang/sdk/issues/1
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hyphen or asterisk, followed by a single space.
- Use a hanging indent for
longer lines
See also:
1.9.4