diff --git a/Documentation/prolog-cookbook.txt b/Documentation/prolog-cookbook.txt
index e660067..f112894 100644
--- a/Documentation/prolog-cookbook.txt
+++ b/Documentation/prolog-cookbook.txt
@@ -28,6 +28,27 @@
 link:http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.2.2.html[Gerrit
 2.2.2 ReleaseNotes] introduces Prolog support in Gerrit.
 
+Submit Type
+-----------
+A 'Submit Type' is a strategy that is used on submit to integrate the
+change into the destination branch. Supported submit types are:
+
+* `Fast Forward Only`
+* `Merge If Necessary`
+* `Merge Always`
+* `Cherry Pick`
+* `Rebase If Necessary`
+
+'Submit Type' is a project global setting. This means that the same submit type
+is used for all changes of one project.
+
+Projects which need more flexibility in choosing, or enforcing, a submit type
+can use Prolog based submit type which replaces the project's default submit
+type.
+
+Prolog based submit type computes a submit type for each change. The computed
+submit type is shown on the change screen for each change.
+
 Prolog Language
 ---------------
 This document is not a complete Prolog tutorial.
@@ -76,6 +97,7 @@
   $ git push origin HEAD:refs/meta/config
 ====
 
+[[HowToWriteSubmitRules]]
 How to write submit rules
 -------------------------
 Whenever Gerrit needs to evaluate submit rules for a change `C` from project `P` it
@@ -178,6 +200,7 @@
 label is met will probably not be made by explicit voting but, instead, by
 inspecting the facts about the change.
 
+[[SubmitFilter]]
 Submit Filter
 -------------
 Another mechanism of changing the default submit rules is to implement the
@@ -215,7 +238,6 @@
 
 The following "drawing" illustrates the order of the invocation and the chaining
 of the results of the `submit_rule` and `submit_filter` predicates.
-
 ====
   All-Projects
   ^   submit_filter(B, S) :- ...  <4>
@@ -247,6 +269,33 @@
 default implementation of submit rule that is named `gerrit:default_submit` and
 its result will be filtered as described above.
 
+How to write submit type
+------------------------
+Writing custom submit type logic in Prolog is the similar top
+xref:HowToWriteSubmitRules[writing submit rules]. The only difference is that
+one has to implement a `submit_type` predicate (instead of the `submit_rule`)
+and that the return result of the `submit_type` has to be an atom that
+represents one of the supported submit types:
+
+* `fast_forward_only`
+* `merge_if_necessary`
+* `merge_always`
+* `cherry_pick`
+* `rebase_if_necessary`
+
+Submit Type Filter
+------------------
+Submit type filter works the same way as the xref:SubmitFilter[Submit Filter]
+where the name of the filter predicate is `submit_type_filter`.
+
+====
+  submit_type_filter(In, Out).
+====
+
+Gerrit will invoke `submit_type_filter` with the `In` parameter containing a
+result of the `submit_type` and will take the value of the `Out` parameter as
+the result.
+
 [[TestingSubmitRules]]
 Testing submit rules
 --------------------
@@ -275,8 +324,8 @@
 the change exposed to them. Gerrit plugins get full access to Gerrit internals
 and can potentially check more things than Prolog based rules.
 
-Examples
---------
+Examples - Submit Rule
+----------------------
 The following examples should serve as a cookbook for developing own submit rules.
 Some of them are too trivial to be used in production and their only purpose is
 to provide step by step introduction and understanding.
@@ -745,6 +794,68 @@
   only_allow_author_to_submit(S1, [label('Patchset-Author', need(_)) | S1]).
 ====
 
+Examples - Submit Type
+----------------------
+The following examples show how to implement own submit type rules.
+
+Example 1: Set a `Cherry Pick` submit type for all changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This example sets the `Cherry Pick` submit type for all changes. It overrides
+whatever is set as project default submit type.
+
+rules.pl
+[caption=""]
+====
+  submit_type(cherry_pick).
+====
+
+
+Example 2: `Fast Forward Only` for all `refs/heads/stable*` branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+For all `refs/heads/stable.*` branches we would like to enforce the `Fast
+Forward Only` submit type. A reason for this decision may be a need to never
+break the build in the stable branches.  For all other branches, those not
+matching the `refs/heads/stable.*` pattern, we would like to use the project's
+default submit type as defined on the project settings page.
+
+.rules.pl
+[caption=""]
+====
+  submit_type(fast_forward_only) :-
+    gerrit:change_branch(B), regex_matches('refs/heads/stable.*', B),
+    !.
+  submit_type(T) :- gerrit:project_default_submit_type(T)
+====
+
+The first `submit_type` predicate defines the `Fast Forward Only` submit type
+for `refs/heads/stable.*` branches. The second `submit_type` predicate returns
+the project's default submit type.
+
+Example 3: Don't require `Fast Forward Only` if only documentation was changed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Like in the previous example we want the `Fast Forward Only` submit type for
+the `refs/heads/stable*` branches.  However, if only documentation was changed
+(only `*.txt` files), then we allow project's default submit type for such
+changes.
+
+.rules.pl
+[caption=""]
+====
+  submit_type(fast_forward_only) :-
+    gerrit:commit_delta('(?<!\.txt)$'),
+    gerrit:change_branch(B), regex_matches('refs/heads/stable.*', B),
+    !.
+  submit_type(T) :- gerrit:project_default_submit_type(T)
+====
+
+The `gerrit:commit_delta('(?<!\.txt)$')` succeeds if the change contains a file
+whose name doesn't end with `.txt` The rest of this rule is same like in the
+previous example.
+
+If all file names in the change end with `.txt`, then the
+`gerrit:commit_delta('(?<!\.txt)$')` will fail as no file name will match this
+regular expression.
+
 GERRIT
 ------
 Part of link:index.html[Gerrit Code Review]