diff --git a/Documentation/access-control.txt b/Documentation/access-control.txt
index cd9bb4d..b082339 100644
--- a/Documentation/access-control.txt
+++ b/Documentation/access-control.txt
@@ -210,8 +210,8 @@
 
 Permissions can be set on a single reference name to match one
 branch (e.g. `refs/heads/master`), or on a reference namespace
-(e.g. `refs/heads/*`) to match any branch starting with that
-prefix. So a permission with `refs/heads/*` will match
+(e.g. `+refs/heads/*+`) to match any branch starting with that
+prefix. So a permission with `+refs/heads/*+` will match
 `refs/heads/master` and `refs/heads/experimental`, etc.
 
 Reference names can also be described with a regular expression
@@ -227,7 +227,7 @@
 References can have the current user name automatically included,
 creating dynamic access controls that change to match the currently
 logged in user.  For example to provide a personal sandbox space
-to all developers, `refs/heads/sandbox/${username}/*` allowing
+to all developers, `+refs/heads/sandbox/${username}/*+` allowing
 the user 'joe' to use 'refs/heads/sandbox/joe/foo'.
 
 When evaluating a reference-level access right, Gerrit will use
@@ -405,19 +405,19 @@
 
 ==== refs/publish/*
 
-`refs/publish/*` is an alternative name to `refs/for/*` when pushing new changes
+`+refs/publish/*+` is an alternative name to `+refs/for/*+` when pushing new changes
 and patch sets.
 
 
 ==== refs/drafts/*
 
-Push to `refs/drafts/*` creates a change like push to `refs/for/*`, except the
+Push to `+refs/drafts/*+` creates a change like push to `+refs/for/*+`, except the
 resulting change remains hidden from public review.  You then have the option
 of adding individual reviewers before making the change public to all.  The
 change page will have a 'Publish' button which allows you to convert individual
 draft patch sets of a change into public patch sets for review.
 
-To block push permission to `refs/drafts/*` the following permission rule can
+To block push permission to `+refs/drafts/*+` the following permission rule can
 be configured:
 
 ====
@@ -464,18 +464,18 @@
 as well as bypass review for new commits on that branch.
 
 To push lightweight (non-annotated) tags, grant
-`Create Reference` for reference name `refs/tags/*`, as lightweight
+`Create Reference` for reference name `+refs/tags/*+`, as lightweight
 tags are implemented just like branches in Git.
 
 For example, to grant the possibility to create new branches under the
 namespace `foo`, you have to grant this permission on
-`refs/heads/foo/*` for the group that should have it.
+`+refs/heads/foo/*+` for the group that should have it.
 Finally, if you plan to grant each user a personal namespace in
 where they are free to create as many branches as they wish, you
 should grant the create reference permission so it's possible
 to create new branches. This is done by using the special
 `${username}` keyword in the reference pattern, e.g.
-`refs/heads/sandbox/${username}/*`. If you do, it's also recommended
+`+refs/heads/sandbox/${username}/*+`. If you do, it's also recommended
 you grant the users the push force permission to be able to clean up
 stale branches.
 
@@ -547,7 +547,7 @@
 Ownership over a particular branch subspace may be delegated by
 entering a branch pattern.  To delegate control over all branches
 that begin with `qa/` to the QA group, add `Owner` category
-for reference `refs/heads/qa/*`.  Members of the QA group can
+for reference `+refs/heads/qa/*+`.  Members of the QA group can
 further refine access, but only for references that begin with
 `refs/heads/qa/`. See <<project_owners,project owners>> to find
 out more about this role.
@@ -600,15 +600,15 @@
 have the `Read` access granted to upload a change.
 
 For an open source, public Gerrit installation, it is common to
-grant `Read` and `Push` for `refs/for/refs/heads/*`
+grant `Read` and `Push` for `+refs/for/refs/heads/*+`
 to `Registered Users` in the `All-Projects` ACL.  For more
 private installations, its common to simply grant `Read` and
-`Push` for `refs/for/refs/heads/*` to all users of a project.
+`Push` for `+refs/for/refs/heads/*+` to all users of a project.
 
 * Force option
 +
 The force option has no function when granted to a branch in the
-`refs/for/refs/heads/*` namespace.
+`+refs/for/refs/heads/*+` namespace.
 
 
 [[category_push_merge]]
@@ -661,11 +661,11 @@
 
 To push lightweight (non annotated) tags, grant
 <<category_create,`Create Reference`>> for reference name
-`refs/tags/*`, as lightweight tags are implemented just like
+`+refs/tags/*+`, as lightweight tags are implemented just like
 branches in Git.
 
 To delete or overwrite an existing tag, grant `Push` with the force
-option enabled for reference name `refs/tags/*`, as deleting a tag
+option enabled for reference name `+refs/tags/*+`, as deleting a tag
 requires the same permission as deleting a branch.
 
 
@@ -1026,7 +1026,7 @@
 
 == Enforcing site wide access policies
 
-By granting the <<category_owner,`Owner`>> access right on the `refs/*` to a
+By granting the <<category_owner,`Owner`>> access right on the `+refs/*+` to a
 group, Gerrit administrators can delegate the responsibility of maintaining
 access rights for that project to that group.
 
diff --git a/Documentation/config-gerrit.txt b/Documentation/config-gerrit.txt
index 2c8b5dd..a4f661a 100644
--- a/Documentation/config-gerrit.txt
+++ b/Documentation/config-gerrit.txt
@@ -2576,8 +2576,8 @@
 If set to true, files with the MIME type `<name>` will be sent as
 direct downloads to the user's browser, rather than being wrapped up
 inside of zipped archives.  The type name may be a complete type
-name, e.g. `image/gif`, a generic media type, e.g. `image/*`,
-or the wildcard `*/*` to match all types.
+name, e.g. `image/gif`, a generic media type, e.g. `+image/*+`,
+or the wildcard `+*/*+` to match all types.
 +
 By default, false for all MIME types.
 
diff --git a/Documentation/config-gitweb.txt b/Documentation/config-gitweb.txt
index d1cee57..2311184 100644
--- a/Documentation/config-gitweb.txt
+++ b/Documentation/config-gitweb.txt
@@ -215,7 +215,7 @@
 
 The CGI's `$projectroot` should be the same directory as
 gerrit.basePath, or a fairly current replica.  If a replica is
-being used, ensure it uses a full mirror, so the `refs/changes/*`
+being used, ensure it uses a full mirror, so the `+refs/changes/*+`
 namespace is available.
 
 ----
diff --git a/Documentation/config-project-config.txt b/Documentation/config-project-config.txt
index 0866875..276117b 100644
--- a/Documentation/config-project-config.txt
+++ b/Documentation/config-project-config.txt
@@ -64,7 +64,7 @@
 The link:#project-section[+project+ section] appears once per project.
 
 The link:#access-section[+access+ section] appears once per reference pattern,
-such as `refs/*` or `refs/heads/*`.  Only one access section per pattern is
+such as `+refs/*+` or `+refs/heads/*+`.  Only one access section per pattern is
 allowed.  You will find examples of keys and values in each category section
 <<access_category,below>>.
 
diff --git a/Documentation/dev-plugins.txt b/Documentation/dev-plugins.txt
index 8bfac13..f9b66cb 100644
--- a/Documentation/dev-plugins.txt
+++ b/Documentation/dev-plugins.txt
@@ -1692,7 +1692,7 @@
 ----
 
 The auto registration only works for standard servlet mappings like
-`/foo` or `/foo/*`. Regex style bindings must use a Guice ServletModule
+`/foo` or `+/foo/*+`. Regex style bindings must use a Guice ServletModule
 to register the HTTP servlets and declare it explicitly in the manifest
 with the `Gerrit-HttpModule` attribute:
 
@@ -1819,7 +1819,7 @@
 == Documentation
 
 If a plugin does not register a filter or servlet to handle URLs
-`/Documentation/*` or `/static/*`, the core Gerrit server will
+`+/Documentation/*+` or `+/static/*+`, the core Gerrit server will
 automatically export these resources over HTTP from the plugin JAR.
 
 Static resources under the `static/` directory in the JAR will be
diff --git a/Documentation/error-prohibited-by-gerrit.txt b/Documentation/error-prohibited-by-gerrit.txt
index 4c7bf22..3d9bbad 100644
--- a/Documentation/error-prohibited-by-gerrit.txt
+++ b/Documentation/error-prohibited-by-gerrit.txt
@@ -9,32 +9,32 @@
 1. if you push a commit for code review to a branch for which you
    don't have upload permissions (access right
    link:access-control.html#category_push_review['Push'] on
-   `refs/for/refs/heads/*`)
+   `+refs/for/refs/heads/*+`)
 2. if you bypass code review without
    link:access-control.html#category_push_direct['Push'] access right
-   on `refs/heads/*`
+   on `+refs/heads/*+`
 3. if you bypass code review pushing to a non-existing branch without
    link:access-control.html#category_create['Create Reference'] access
-   right on `refs/heads/*`
+   right on `+refs/heads/*+`
 4. if you push an annotated tag without
    link:access-control.html#category_push_annotated['Push Annotated Tag']
-   access right on 'refs/tags/*'
+   access right on `+refs/tags/*+`
 5. if you push a signed tag without
    link:access-control.html#category_push_signed['Push Signed Tag']
-   access right on 'refs/tags/*'
+   access right on `+refs/tags/*+`
 6. if you push a lightweight tag without the access right link:access-control.html#category_create['Create
-   Reference'] for the reference name 'refs/tags/*'
+   Reference'] for the reference name `+refs/tags/*+`
 7. if you push a tag with somebody else as tagger and you don't have the
    link:access-control.html#category_forge_committer['Forge Committer']
-   access right for the reference name 'refs/tags/*'
+   access right for the reference name `+refs/tags/*+`
 8. if you push to a project that is in state 'Read Only'
 
 For new users it often happens that they accidentally try to bypass
 code review. The push then fails with the error message 'prohibited
 by Gerrit' because the project didn't allow to bypass code review.
-Bypassing the code review is done by pushing directly to refs/heads/*
-(e.g. refs/heads/master) instead of pushing to refs/for/* (e.g.
-refs/for/master). Details about how to push commits for code review
+Bypassing the code review is done by pushing directly to `+refs/heads/*+`
+(e.g. `refs/heads/master`) instead of pushing to `+refs/for/*+` (e.g.
+`refs/for/master`). Details about how to push commits for code review
 are explained link:user-upload.html#push_create[here].
 
 
diff --git a/Documentation/intro-project-owner.txt b/Documentation/intro-project-owner.txt
index c55a43c..461aa91 100644
--- a/Documentation/intro-project-owner.txt
+++ b/Documentation/intro-project-owner.txt
@@ -10,7 +10,7 @@
 Being project owner means that you own a project in Gerrit.
 Technically this is expressed by having the
 link:access-control.html#category_owner[Owner] access right on
-`refs/*` on that project. As project owner you have the permission to
+`+refs/*+` on that project. As project owner you have the permission to
 edit the access control list and the project settings of the project.
 It also means that you should get familiar with these settings so that
 you can adapt them to the needs of your project.
@@ -127,12 +127,12 @@
 `refs/heads/master` but also on ref patterns and regular expressions
 for ref names.
 
-A ref pattern ends with `/*` and describes a complete ref name
-namespace, e.g. access rights assigned on `refs/heads/*` apply to all
+A ref pattern ends with `+/*+` and describes a complete ref name
+namespace, e.g. access rights assigned on `+refs/heads/*+` apply to all
 branches.
 
 Regular expressions must start with `^`, e.g. access rights assigned
-on `^refs/heads/rel-.*` would apply to all `rel-*` branches.
+on `+^refs/heads/rel-.*+` would apply to all `+rel-*+` branches.
 
 [[groups]]
 === Groups
diff --git a/Documentation/prolog-cookbook.txt b/Documentation/prolog-cookbook.txt
index 168c042..43caa83 100644
--- a/Documentation/prolog-cookbook.txt
+++ b/Documentation/prolog-cookbook.txt
@@ -987,11 +987,11 @@
 ----
 
 [[SubmitTypePerBranch]]
-=== Example 2: `Fast Forward Only` for all `refs/heads/stable*` branches
-For all `refs/heads/stable*` branches we would like to enforce the `Fast
+=== 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
+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`
@@ -1004,13 +1004,13 @@
 ----
 
 The first `submit_type` predicate defines the `Fast Forward Only` submit type
-for `refs/heads/stable.*` branches. The second `submit_type` predicate returns
+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
+`+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`
diff --git a/Documentation/user-changeid.txt b/Documentation/user-changeid.txt
index b0e365f..44ca6e0 100644
--- a/Documentation/user-changeid.txt
+++ b/Documentation/user-changeid.txt
@@ -70,8 +70,8 @@
 Change Upload
 --------------
 
-During upload by pushing to `refs/for/*`, `refs/drafts/*` or
-`refs/heads/*`, Gerrit will try to find an existing review the
+During upload by pushing to `+refs/for/*+`, `+refs/drafts/*+` or
+`+refs/heads/*+`, Gerrit will try to find an existing review the
 uploaded commit relates to. For an existing review to match, the
 following properties have to match:
 
diff --git a/Documentation/user-dashboards.txt b/Documentation/user-dashboards.txt
index 52916b9..f6db6cf 100644
--- a/Documentation/user-dashboards.txt
+++ b/Documentation/user-dashboards.txt
@@ -58,7 +58,7 @@
 == Project Dashboards
 
 It is possible to share custom dashboards at a project level. To do
-this define the dashboards in a `refs/meta/dashboards/*` branch of the
+this define the dashboards in a `+refs/meta/dashboards/*+` branch of the
 project. For each dashboard create a config file. The file path/name
 will be used as name (equivalent to a title in a custom dashboard) for
 the dashboard.
diff --git a/Documentation/user-upload.txt b/Documentation/user-upload.txt
index 46aa535..de9a2fb 100644
--- a/Documentation/user-upload.txt
+++ b/Documentation/user-upload.txt
@@ -319,9 +319,9 @@
 
 Gerrit restricts direct pushes that bypass review to:
 
-* `refs/heads/*`: any branch can be updated, created, deleted,
+* `+refs/heads/*+`: any branch can be updated, created, deleted,
 or rewritten by the pusher.
-* `refs/tags/*`: annotated tag objects pointing to any other type
+* `+refs/tags/*+`: annotated tag objects pointing to any other type
 of Git object can be created.
 
 To push branches, the proper access rights must be configured first.
@@ -445,8 +445,8 @@
 own process space, Gerrit maintains complete control over how the
 repository is updated, and what responses are sent to the `git push`
 client invoked by the end-user, or by `repo upload`.  This allows
-Gerrit to provide magical refs, such as `refs/for/*` for new
-change submission and `refs/changes/*` for change replacement.
+Gerrit to provide magical refs, such as `+refs/for/*+` for new
+change submission and `+refs/changes/*+` for change replacement.
 When a push request is received to create a ref in one of these
 namespaces Gerrit performs its own logic to update the database,
 and then lies to the client about the result of the operation.