compiler/
kernel/
lib/
scripts/
seed/
sublime/
test/
vim/
.gitignore
336 B
.gitsigners
112 B
CONTRIBUTING
2.1 KiB
LICENSE
1.1 KiB
Makefile
10.2 KiB
README
2.5 KiB
STYLE
2.5 KiB
std.lib
1.5 KiB
std.lib.test
551 B
CONTRIBUTING
raw
| 1 | ============ |
| 2 | CONTRIBUTING |
| 3 | ============ |
| 4 | |
| 5 | When contributing code, please follow these simple guidelines. |
| 6 | |
| 7 | WRITING COMMITS |
| 8 | |
| 9 | 1. Always include a short description of the change in the commit message body, |
| 10 | explaining why the change was made. |
| 11 | 2. In the commit summary, prefix the affected module, if there is one |
| 12 | specifically. |
| 13 | 3. If assisted by a coding agent, affix a commit trailer like: |
| 14 | |
| 15 | Assisted-by: Codex:gpt-5.5 |
| 16 | |
| 17 | 4. Look at existing commit messages to get an idea of the style. |
| 18 | 5. In terms of the message content, if you're fixing something, a good format to |
| 19 | follow is: (a) state the current problematic behavior, (b) state the new, |
| 20 | improved behavior, and optionally (c) state how or why this specific solution |
| 21 | was chosen. One paragraph each. |
| 22 | |
| 23 | A properly formed git commit subject line should always be able to complete the |
| 24 | following sentence: |
| 25 | |
| 26 | If applied, this commit will _____ |
| 27 | |
| 28 | For example, the following message is well formed: |
| 29 | |
| 30 | ui: Add support for .gif files |
| 31 | |
| 32 | In addition, it should be capitalized and *must not* include a period. |
| 33 | |
| 34 | When it comes to formatting, here's a model git commit message[1]: |
| 35 | |
| 36 | Capitalized, short (50 chars or less) summary |
| 37 | |
| 38 | More detailed explanatory text, if necessary. Wrap it to about 72 |
| 39 | characters or so. In some contexts, the first line is treated as the |
| 40 | subject of an email and the rest of the text as the body. The blank |
| 41 | line separating the summary from the body is critical (unless you omit |
| 42 | the body entirely); tools like rebase can get confused if you run the |
| 43 | two together. |
| 44 | |
| 45 | Write your commit message in the imperative: "Fix bug" and not "Fixed bug" |
| 46 | or "Fixes bug." This convention matches up with commit messages generated |
| 47 | by commands like git merge and git revert. |
| 48 | |
| 49 | Further paragraphs come after blank lines. |
| 50 | |
| 51 | - Bullet points are okay, too. |
| 52 | |
| 53 | - Typically a hyphen or asterisk is used for the bullet, followed by a |
| 54 | single space, with blank lines in between, but conventions vary here. |
| 55 | |
| 56 | - Use a hanging indent. |
| 57 | |
| 58 | --- |
| 59 | |
| 60 | [1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html |