• Home
  • Raw
  • Download

Lines Matching +full:- +full:- +full:no +full:- +full:git +full:- +full:commit

12   * BSD 2-Clause (The BSD 2-Clause License)
14 Contributions made up to 2017-06-01 have been made under the dual
15 license model BSD 2-Clause and GPL v2+ (The GNU General Public License
18 The used VCS for libcoap is Git, the main repository is living on GitHub.
28 GNU GCC and the LLVM C-compiler (CLang) are supported. The Windows VS build
39 No matter if you just have a simple question, some specific problem or
45 https://lists.sourceforge.net/lists/listinfo/libcoap-developers
49 https://sourceforge.net/p/libcoap/mailman/libcoap-developers
55 As written above, libcoap is maintained with the Git tools so you should be
56 familiar with the various git commands.
62 To start any contributing you first have to clone the git tree from the main
65 git clone https://github.com/obgm/libcoap.git
75 git checkout develop origin/develop
77 Now you can simply start your own local branch (for example 'my-develop')
81 git checkout -b my-develop
83 At this point you can now work with git, modify the source, commit
87 list (and/or push your changes into your public Git tree). Multiple commits
88 for your branch should be squash'ed into a single commit. This can be done
93 git push origin my-develop
96 for others to review. If changes are needed, then commit and squash changes
99 git push -f origin my-develop
105 single patches, this will be going easy with the 'git format-patch' command
109 To not mix up your series with probably unrelated patches let git place the
110 patches within a defined directory. Also, while create the patches, tell git to
114 git format-patch --cover-letter -o ../patches4libcoap
117 patch named '0000-cover-letter.patch'. Please modify this patch with some
119 your patches to libcoap-developers@lists.sourceforge.net
121 git send-email ../patches4libcoap/* --to=libcoap-developers@lists.sourceforge.net
128 5.1 pre-commit
129 --------------
130 pre-commit is used to check the the syntax of *.c and *.h files according to
131 the libcoap coding rules. The files are checked on github for every 'git push',
132 and can be locally checked if pre-commit is installed for every 'git commit'.
135 $ pip install pre-commit
136 $ pre-commit install --allow-missing-config
139 -------------------------
145 ---------------------------
147 is depended on the often used nested functions like 'if-else'. Don't use
153 --8<----
154 /* -*- Mode: C; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
155 --->8--
170 --8<----
177 --->8--
180 -----------------------------
188 @-syntax for doxygen commands (akin to javadoc).
191 ---------------
199 -----------------------
200 * Git commits must be atomic and contain a declarative subject line (max 50
202 Use the opportunity to write a good explanation why your patch/commit is to
205 way. Don't use something to generic like "bugfix commit".
207 * A patch/commit or a series of patches/commits have to ensure that the
211 * Every patch/commit should handle one single logical change. If more than
212 one patch/commit is needed for a change explain it, respect the point
214 typically your patch is to big for one single commit.
216 * Commit message should begin with a submodule or unit the commit is for.
217 Doing this in your commit message helps to find thematic other changes. If
218 you have to search and find something with 'git log | grep [foo]' you will
221 rd.c: Fixed type-specifier warning
256 Unfortunately there is no good user guide on how to use the libcoap in
257 any external project. This means there is no HowTo or CheatSheet for a