raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11

remove requirement for module tag in commit message, fixes #19413

Browse source
This commit is contained in:
Roland Kuhn 2016-02-16 11:56:29 +01:00
parent f820d90061
commit 67d5cc1471
1 changed files with 3 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

11
CONTRIBUTING.md
View file

@ -153,14 +153,9 @@ Follow these guidelines when creating public commits and writing commit messages
1. If your work spans multiple local commits (for example; if you do safe point commits while working in a feature branch or work in a branch for a long time doing merges/rebases etc.) then please do not commit it all but rewrite the history by squashing the commits into a single big commit which you write a good commit message for (like discussed in the following sections). For more info read this article: [Git Workflow](http://sandofsky.com/blog/git-workflow.html). Every commit should be able to be used in isolation, cherry picked etc. 1. If your work spans multiple local commits (for example; if you do safe point commits while working in a feature branch or work in a branch for a long time doing merges/rebases etc.) then please do not commit it all but rewrite the history by squashing the commits into a single big commit which you write a good commit message for (like discussed in the following sections). For more info read this article: [Git Workflow](http://sandofsky.com/blog/git-workflow.html). Every commit should be able to be used in isolation, cherry picked etc.
2. First line should be a descriptive sentence what the commit is doing. It should be possible to fully understand what the commit does—but not necessarily how it does it—by just reading this single line. We follow the “imperative present tense” style for commit messages ([more info here](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)). 2. First line should be a descriptive sentence what the commit is doing, including the ticket number. It should be possible to fully understand what the commit does—but not necessarily how it does it—by just reading this single line. We follow the “imperative present tense” style for commit messages ([more info here](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)).
It is **not ok** to only list the ticket number, type "minor fix" or similar. In order to help with automatic filtering of the commit history (generating ChangeLogs, writing the migration guide, code archaeology) we use the following encoding:
* the first character is either '!' (for breaking API changes), '+' (for non-breaking API additions) or '=' (for API-neutral commits)
* then follows a comma-separated list of module abbreviations, formed by using the first three letters of the module name (the “akka-” prefix being stripped off), e.g. `act`, `clu`, `doc`; it is intentional that `akka-actor-tests` receives the same abbreviation as `akka-actor`. For commits modifying the project itself (sbt files or anything in `project/`) please use `pro`.
* then follows a space character, a hash sign '#' and the ticket number
* the rest of the line (usually there are 64 characters left) makes up the textual summary
It is **not ok** to only list the ticket number, type "minor fix" or similar.
If the commit is a small fix, then you are done. If not, go to 3. If the commit is a small fix, then you are done. If not, go to 3.
3. Following the single line description should be a blank line followed by an enumerated list with the details of the commit. 3. Following the single line description should be a blank line followed by an enumerated list with the details of the commit.
@ -170,7 +165,7 @@ Follow these guidelines when creating public commits and writing commit messages
Example: Example:
+act #2731 Adding monadic API to Future enable Travis CI #1
* Details 1 * Details 1
* Details 2 * Details 2