]>
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. | |
9 | 2. Create a new branch based on the `develop` branch (`git checkout -b your_branch develop`). | |
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 | |
13 | output of `git branch` easier to understand with a single glance. | |
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 TL |
21 | mkdir build |
22 | cd build | |
23 | cmake .. | |
24 | cmake --build . --target check | |
7c673cae FG |
25 | ``` |
26 | 5. Commit your changes. Your commit message should start with a one line | |
27 | short description of the modifications, with the details and explanations | |
28 | of your modifications following in subsequent paragraphs or bullet points. | |
29 | Please limit your lines to about 78 characters in commit messages, since | |
30 | it makes the output easier to read in `git log`. Also, starting your commit | |
31 | message with a tag describing the nature of the commit is nice, since it | |
32 | makes the commit history easier to skim through. For commits that do not | |
33 | change any functionality (e.g. refactoring or fixing typos), the `[NFC]` | |
34 | tag (No Functionality Change) can be used. Here's an example of an | |
35 | acceptable commit message: | |
36 | ``` | |
37 | [Searchable] Refactor the interface | |
38 | ||
39 | - Rename elem to contains | |
40 | - Rename subset to is_subset, and make is_subset applicable in infix notation | |
41 | - Add the at_key method | |
42 | - operator[] is now bound to at_key instead of find | |
43 | ``` | |
44 | When applicable, please squash adjacent _wip_ commits into a single | |
45 | _logical_ commit. If your contribution has several logical commits, | |
46 | it's fine. | |
47 | 6. Push the changes to your fork (`git push origin your_branch`). | |
48 | 7. Open a pull request against Hana's `develop` branch (not against `master`). | |
49 | I will do my best to respond in a timely manner. I might discuss your patch | |
50 | and suggest some modifications, or I might amend your patch myself and ask | |
51 | you for feedback. You will always be given proper credit. | |
52 | ||
53 | ||
54 | ## Style guide | |
55 | ||
56 | I'm not going to write an exhaustive style guide, but here are a couple of | |
57 | points you should watch out for: | |
58 | - Indent using 4 spaces. | |
59 | - Do not leave trailing white spaces at the end of lines, and no more than a | |
60 | single newline at the end of a source file. | |
61 | - Hana's `#include`s go first, then a blank line and system headers. | |
62 | `#include`s within each block should be sorted in alphabetical order. | |
63 | - Use your own judgment and stick to the style of the surrounding code. |