/
CONTRIBUTE
33 lines (28 loc) · 1.4 KB
/
CONTRIBUTE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
So you want to contribute? That's great, thank you! Here are some tips that
will help you make us cry with delight at the very sight of your patch:
Patch format
------------
- It's best if the patches are directly processable by Git (such as when using
`git-format-patch', `git-send-email' or the ---8<--- scissors trick).
- A nice way to have Git produce better diff hunk headers when working with
Lisp code is to add this to your config:
[diff "lisp"]
xfuncname = "^\\(.*$"
With this and an appropriate diff attribute definition (provided by the
.gitattributes file in the repository), it will be immediately visible
which top level Lisp form a particular hunk pertains to.
Commit messages
---------------
- The first line is a commit summary, usually a single sentence in imperative
short enough to fit in a mail subject line. It starts with a capital letter,
but does not end with a period.
- After that and a blank line comes the commit message with a free form
explanation (optional for trivial patches).
General coding guidelines
-------------------------
- Keep it inside 80 columns when possible.
- Avoid trailing whitespace (Git can help you with that).
- Avoid tabs (set `indent-tabs-mode' to nil).
- If you're making bigger changes, it's a good idea to try byte-compiling
Vimpulse even though you normally don't (the compiler sometimes catches
issues not obvious when running uncompiled).