Permalink
November 23, 2016 15:00
November 17, 2016 15:02
November 17, 2016 15:02
November 17, 2016 15:02
November 17, 2016 15:14
November 17, 2016 15:02
November 17, 2016 15:14
November 17, 2016 15:02
November 17, 2016 15:02
November 17, 2016 15:02
November 17, 2016 15:02
November 23, 2016 15:13
November 17, 2016 15:02
November 23, 2016 11:24
November 17, 2016 15:02
November 17, 2016 15:02
November 17, 2016 15:02
November 17, 2016 15:10
Newer
100644
87 lines (65 sloc)
3.45 KB
1
Here are some guidelines for people who want to make changes
2
to this repository.
3
6
10
characters is the soft limit, see DISCUSSION in git-commit(1)), and
11
should skip the full stop. It is also conventional in most cases to
12
prefix the first line with "project: " where the project is a filename
13
or identifier for the project, the Bee file is for, e.g.
14
17
18
The description is a summary, and should be a statement, that means, it
19
has to contain a verb. Best, start the statement with a verb in
20
imperative mood.
21
22
If in doubt which identifier to use, run "git log --no-merges" on the
23
files you are modifying to see the current conventions.
24
25
The body should provide a meaningful commit message, which:
26
28
with the current code without the change.
29
31
result with the change is better.
32
34
35
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
36
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
37
to do frotz", as if you are giving orders to the codebase to change
38
its behaviour. Try to make sure your explanation can be understood
39
without external resources. Instead of giving a URL to a mailing list
40
archive, summarize the relevant points of the discussion.
41
42
If you want to reference a previous commit in the history of a stable
43
branch, use the format "abbreviated sha1 (subject, date)",
44
with the subject enclosed in a pair of double-quotes, like this:
45
46
Commit f86a374 ("pack-bitmap.c: fix a memleak", 2015-03-30)
47
noticed that ...
48
49
The "Copy commit summary" command of gitk can be used to obtain this
50
format.
51
52
If your description starts to get too long, that's a sign that you
53
probably need to split up your commit to finer grained pieces.
54
That being said, patches which plainly describe the things that
55
help reviewers check the patch, and future maintainers understand
56
the code, are the most beautiful patches. Descriptions that summarise
57
the point in the subject well, and describe the motivation for the
58
change, the approach taken by the change, and if relevant how this
59
differs substantially from the prior version, are all good things
60
to have.
61
62
Oh, another thing. We are picky about whitespaces. Make sure your
63
changes do not trigger errors with the sample pre-commit hook shipped
64
in templates/hooks--pre-commit. To help ensure this does not happen,
65
run git diff --check on your changes before you commit.
66
68
Publish your work in a separate branch.
69
=======================================
70
71
Please make sure your patch does not add commented out debugging code,
72
or include any extra files which do not relate to what your patch
73
is trying to achieve. Make sure to review
74
your patch after generating it, to ensure accuracy. Before
75
sending out, please make sure it cleanly applies to the "master"
77
80
81
You often want to add additional explanation about the patch,
82
other than the commit message itself.