@@ -15,7 +15,9 @@ from them into your own application.
15
15
16
16
## Discussion & Chat
17
17
18
- We hang out in the #libgit2 channel on irc.freenode.net.
18
+ We hang out in the
19
+ [ ` #libgit2 ` ] ( http://webchat.freenode.net/?channels=#libgit2 ) ) channel on
20
+ irc.freenode.net.
19
21
20
22
Also, feel free to open an
21
23
[ Issue] ( https://github.com/libgit2/libgit2/issues/new ) to start a discussion
@@ -34,10 +36,10 @@ and when a critical bug fix needs to be backported, it will be done on a
34
36
35
37
First, know which version of libgit2 your problem is in and include it in
36
38
your bug report. This can either be a tag (e.g.
37
- [ v0.17.0] ( https://github.com/libgit2/libgit2/releases/tag/v0.17.0 ) ) or a
38
- commit SHA (e.g.
39
- [ 01be7863] ( https://github.com/libgit2/libgit2/commit/01be786319238fd6507a08316d1c265c1a89407f )
40
- ). Using [ ` git describe ` ] ( http://git-scm.com/docs/git-describe ) is a
39
+ [ v0.17.0] ( https://github.com/libgit2/libgit2/releases/tag/v0.17.0 ) ) or a
40
+ commit SHA
41
+ (e.g. [ 01be7863] ( https://github.com/libgit2/libgit2/commit/01be7863 ) ).
42
+ Using [ ` git describe ` ] ( http://git-scm.com/docs/git-describe ) is a
41
43
great way to tell us what version you're working with.
42
44
43
45
If you're not running against the latest ` master ` branch version,
@@ -52,11 +54,13 @@ out a way to help you.
52
54
53
55
## Pull Requests
54
56
55
- Our work flow is a [ typical GitHub flow] ( https://guides.github.com/introduction/flow/index.html ) ,
56
- where contributors fork the [ libgit2 repository] ( https://github.com/libgit2/libgit2 ) ,
57
+ Our work flow is a [ typical GitHub
58
+ flow] ( https://guides.github.com/introduction/flow/index.html ) , where
59
+ contributors fork the [ libgit2 repository] ( https://github.com/libgit2/libgit2 ) ,
57
60
make their changes on branch, and submit a
58
- [ Pull Request] ( https://help.github.com/articles/using-pull-requests ) (a.k.a. "PR").
59
- Pull requests should usually be targeted at the ` master ` branch.
61
+ [ Pull Request] ( https://help.github.com/articles/using-pull-requests )
62
+ (a.k.a. "PR"). Pull requests should usually be targeted at the ` master `
63
+ branch.
60
64
61
65
Life will be a lot easier for you (and us) if you follow this pattern
62
66
(i.e. fork, named branch, submit PR). If you use your fork's ` master `
@@ -75,11 +79,32 @@ also let others know that you are currently working on something.
75
79
76
80
Before wrapping up a PR, you should be sure to:
77
81
78
- * Write tests to cover any functional changes (ideally tests that would
79
- have failed before the PR and now pass)
82
+ * Write tests to cover any functional changes
80
83
* Update documentation for any changed public APIs
81
84
* Add to the [ ` CHANGELOG.md ` ] ( CHANGELOG.md ) file describing any major changes
82
85
86
+ ## Unit Tests
87
+
88
+ We believe that our unit tests allow us to keep the quality of libgit2
89
+ high: any new changes must not cause unit test failures, and new changes
90
+ should include unit tests that cover the bug fixes or new features.
91
+ For bug fixes, we prefer unit tests that illustrate the failure before
92
+ the change, but pass with your changes.
93
+
94
+ In addition to new tests, please ensure that your changes do not cause
95
+ any other test failures. Running the entire test suite is helpful
96
+ before you submit a pull request. When you build libgit2, the test
97
+ suite will also be built. You can run all tests by simply running
98
+ the resultant ` libgit2_clar ` binary. If you want to run a specific
99
+ unit test, you can name it with the ` -s ` option. For example:
100
+
101
+ libgit2_clar -sstatus::worktree::long_filenames
102
+
103
+ Or you can run an entire class of tests. For example, to run all the
104
+ worktree status tests:
105
+
106
+ libgit2_clar -sstatus::worktree
107
+
83
108
## Porting Code From Other Open-Source Projects
84
109
85
110
` libgit2 ` is licensed under the terms of the GPL v2 with a linking
@@ -112,9 +137,10 @@ function and type naming, code formatting, and testing.
112
137
113
138
We like to keep the source code consistent and easy to read. Maintaining
114
139
this takes some discipline, but it's been more than worth it. Take a look
115
- at the
116
- [ conventions file] ( https://github.com/libgit2/libgit2/blob/development/CONVENTIONS.md ) .
140
+ at the [ conventions
141
+ file] ( https://github.com/libgit2/libgit2/blob/development/CONVENTIONS.md ) .
117
142
118
143
## Starter Projects
119
144
120
- See our [ projects list] ( https://github.com/libgit2/libgit2/blob/development/PROJECTS.md ) .
145
+ See our [ projects
146
+ list] ( https://github.com/libgit2/libgit2/blob/development/PROJECTS.md ) .
0 commit comments