Lines Matching +full:commit +full:- +full:message
5 ---------------
8 [GitLab merge requests](https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html).
15 Wayland formerly accepted patches via `git-send-email`, sent to
16 **wayland-devel@lists.freedesktop.org**; these were
24 ---------------------------------
27 [linear, 'recipe' style history](http://www.bitsnbites.eu/git-history-work-log-vs-recipe/).
28 This means that every commit should be small, digestible, stand-alone, and
29 functional. Rather than a purely chronological commit history like this:
33 connection: init fds to -1
42 connection: Clear fds we shouldn't close to -1
48 The first line of a commit message should contain a prefix indicating
61 The body of the commit message should describe what the patch changes
64 a commit message for an obvious change, so an empty commit message
66 answered on the one-line summary.
68 The lines of the commit message should have at most 76 characters, to
71 See [notes on commit messages] for a recommended reading on writing commit
74 Your patches should also include a Signed-off-by line with your name and
76 also gather S-o-b's by them (and/or whomever gave the patch to you.) The
82 We won't reject patches that lack S-o-b, but it is strongly recommended.
84 When you re-send patches, revised or not, it would be very good to document the
85 changes compared to the previous revision in the commit message and/or the
86 merge request. If you have already received Reviewed-by or Acked-by tags, you
88 commit messages. Otherwise the tags may be lost, reviewers miss the credit they
93 ---------------------------------
102 You should use `git rebase -i` to make revisions, so that your patches follow
116 that they still individually look good, then force-push your new branch to
121 [many GitLab CLI clients](https://about.gitlab.com/applications/#cli-clients),
129 ------------
137 - indent with tabs, and a tab is always 8 characters wide
138 - opening braces are on the same line as the if statement;
139 - no braces in an if-body with just one statement;
140 - if one of the branches of an if-else condition has braces, then the
142 - there is always an empty line between variable declarations and the
165 - lines should be less than 80 characters wide;
166 - when breaking lines with functions calls, the parameters are aligned
168 - when assigning a variable with the result of a function call, if the
202 same, with the exception of a no-advertising clause in X11 not included
213 (Reviewed-by). Additionally, if no Reviewed-by's have been given by
214 people with commit access, there needs to be at least one Acked-by from
215 someone with commit access. A person with commit access is expected to be
220 ignored. We rely very much on the judgement of reviewers and commit rights
225 - The commit message explains why the change is being made.
227 - The code fits the project's scope.
229 - The code license is the same MIT licence the project generally uses.
231 - Stable ABI or API is not broken.
233 - Stable ABI or API additions must be justified by actual use cases, not only
237 - The code fits the existing software architecture, e.g. no layering
240 - The code is correct and does not introduce new failures for existing users,
241 does not add new corner-case bugs, and does not introduce new compiler
244 - The patch does what it says in the commit message and changes nothing else.
246 - The patch is a single logical change. If the commit message addresses
247 multiple points, it is a hint that the commit might need splitting up.
249 - A bug fix should target the underlying root cause instead of hiding symptoms.
253 - The bug root cause rule applies to external software components as well, e.g.
256 - The test suite passes.
258 - The code does not depend on API or ABI which has no working free open source
261 - The code is not dead or untestable. E.g. if there are no free open source
264 - The code is written to be easy to understand, or if code cannot be clear
267 - The code is minimal, i.e. prefer refactor and re-use when possible unless
270 - The code adheres to the style guidelines.
272 - In a patch series, every intermediate step adheres to the above guidelines.
275 Commit rights
278 Commit rights will be granted to anyone who requests them and fulfills the
281 - Submitted some (10 as a rule of thumb) non-trivial (not just simple
285 - Are actively participating in public discussions about their work (on the
288 one-way communication. Cross-review is still highly encouraged.
290 - Will be regularly contributing further patches. This includes regular
294 - Agrees to use their commit rights in accordance with the documented merge
297 To apply for commit rights, create a new issue in gitlab for the respective
300 Committers are encouraged to request their commit rights get removed when they
301 no longer contribute to the project. Commit rights will be reinstated when they
304 Maintainers and committers should encourage contributors to request commit
315 - **Alpha release**:
321 - **Beta release**:
324 new features that are not major, low risk changes, clean-ups, and
328 - **Release candidates (RC)**:
334 - **Stable release**:
343 [git documentation]: http://git-scm.com/documentation
344 [notes on commit messages]: http://who-t.blogspot.de/2009/12/on-commit-messages.html