]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | # How to contribute |
2 | ||
3 | Contributions are always very much appreciated. However, to make sure the | |
4 | process of accepting patches goes smoothly for everyone (especially for | |
5 | the maintainer), you should try to follow these few simple guidelines when | |
6 | you contribute: | |
7 | ||
8 | 1. Fork the repository. | |
f51cf556 | 9 | 2. Create a new branch based on the `master` branch (`git checkout -b your_branch master`). |
7c673cae FG |
10 | If your contribution is a bug fix, you should name your branch `bugfix/xxx`; |
11 | for a feature, it should be `feature/xxx`. Otherwise, just use your good | |
12 | judgment. Consistent naming of branches is appreciated since it makes the | |
f51cf556 | 13 | output of `git branch` easier to understand at a single glance. |
7c673cae FG |
14 | 3. Do your modifications on that branch. Except for special cases, your |
15 | contribution should include proper unit tests and documentation. Also, | |
16 | please try to follow the style guide below. | |
17 | 4. Make sure your modifications did not break anything by building and | |
18 | running the tests: | |
19 | ||
20 | ```shell | |
92f5a8d4 | 21 | mkdir build |
f51cf556 TL |
22 | cmake -S . -B build |
23 | cmake --build build --target check | |
7c673cae FG |
24 | ``` |
25 | 5. Commit your changes. Your commit message should start with a one line | |
26 | short description of the modifications, with the details and explanations | |
27 | of your modifications following in subsequent paragraphs or bullet points. | |
28 | Please limit your lines to about 78 characters in commit messages, since | |
29 | it makes the output easier to read in `git log`. Also, starting your commit | |
30 | message with a tag describing the nature of the commit is nice, since it | |
31 | makes the commit history easier to skim through. For commits that do not | |
32 | change any functionality (e.g. refactoring or fixing typos), the `[NFC]` | |
33 | tag (No Functionality Change) can be used. Here's an example of an | |
34 | acceptable commit message: | |
35 | ``` | |
36 | [Searchable] Refactor the interface | |
37 | ||
38 | - Rename elem to contains | |
39 | - Rename subset to is_subset, and make is_subset applicable in infix notation | |
40 | - Add the at_key method | |
41 | - operator[] is now bound to at_key instead of find | |
42 | ``` | |
43 | When applicable, please squash adjacent _wip_ commits into a single | |
44 | _logical_ commit. If your contribution has several logical commits, | |
45 | it's fine. | |
46 | 6. Push the changes to your fork (`git push origin your_branch`). | |
f51cf556 TL |
47 | 7. Open a pull request against Hana's `master` branch. I will do my best to respond |
48 | in a timely manner. I might discuss your patch and suggest some modifications, | |
49 | or I might amend your patch myself and ask you for feedback. You will always be | |
50 | given proper credit. | |
7c673cae FG |
51 | |
52 | ||
53 | ## Style guide | |
54 | ||
55 | I'm not going to write an exhaustive style guide, but here are a couple of | |
56 | points you should watch out for: | |
57 | - Indent using 4 spaces. | |
58 | - Do not leave trailing white spaces at the end of lines, and no more than a | |
59 | single newline at the end of a source file. | |
60 | - Hana's `#include`s go first, then a blank line and system headers. | |
61 | `#include`s within each block should be sorted in alphabetical order. | |
62 | - Use your own judgment and stick to the style of the surrounding code. |