Lines Matching +full:commit +full:- +full:message

3 - Indentation in tabs, 8 characters wide, spaces after the tabs where
9 - Max line width 80ch, do not break up printed strings though
11 - Break up long lines at logical groupings, one line for each logical group
27 - Function declarations: return type on separate line, {} on separate line,
45 - `/* comments only */`, no `// comments`
47 - `variable_name`, not `VariableName` or `variableName`. same for functions.
49 - no typedefs of structs, enums, unions
51 - if it generates a compiler warning, it needs to be fixed
52 - if it generates a static checker warning, it needs to be fixed or
55 - declare variables when they are used first and try to keep them as local as possible.
78 - avoid uninitialized variables where possible, declare them late instead.
102 - avoid calling non-obvious functions inside declaration blocks for multiple
125   There is a bit of gut-feeling involved with this, but the goal is to make
128 - Where statements are near-identical and repeated, try to keep them
152 - if/else: { on the same line, no curly braces if both blocks are a single
165 - public functions MUST be doxygen-commented, use doxygen's `@foo` rather than
168 - `#include "config.h"` comes first, followed by system headers, followed by
180 #include "libinput-private.h"
183 - goto jumps only to the end of the function, and only for good reasons
186 - Use stdbool.h's bool for booleans within the library (instead of `int`).
189 # Git commit message requirements
191 Our CI will check the commit messages for a few requirements. Below is the
192 list of what we expect from a git commit.
194 ## Commit message content
196 A [good commit message](http://who-t.blogspot.com/2009/12/on-commit-messages.html) needs to
199 - Why is it necessary? It may fix a bug, it may add a feature, it may
202 - How does it address the issue? For short obvious patches this part can be
205 - What effects does the patch have? (In addition to the obvious ones, this
210 the approach chosen was correct. A good commit message also helps
214 ## Commit message format
216 The canonical git commit message format is:
219 one line as the subject line with a high-level note
222 can be multiple paragraphs and is largely free-form. Markdown is not
226 - benchmark one says 10s
227 - benchmark two says 12s
230 The subject line is the first thing everyone sees about this commit, so make
233 ## Commit message technical requirements
235 - The commit message should use present tense (not past tense). Do write
237 - The text width of the commit should be 78 chars or less, especially the
239 - The author must be the name you usually identify as and email address. We do
242   git config --global user.name Your Name
243   git config --global user.email your@email