Work around asciidoctor handling of nested ` and *
In asciidoctor, the markup
`refs/heads/foo/*` for
[...]
`refs/heads/sandbox/${username}/*`. If you do,
renders as
<code>refs/heads/foo/<strong></code> for
[...]
<code>refs/heads/sandbox/${username}/</strong></code>. If you do,
which is problematic in a few ways:
- it is invalid HTML
- the asterisks are swallowed
- a section of unrelated text is made bold
Since asciidoc 8.4.1, by contrast, backticks introduce an inline literal
inside which markup is not interpreted (see git.git commit v1.7.10.3~16^2,
"docs: stop using asciidoc no-inline-literal", 2012-04-26). We can
emulate that behavior in asciidoctor by explicitly introducing inline
literal context using '+'.
https://github.com/asciidoctor/asciidoctor/issues/718 has more details.
Change-Id: Iab31e33f92929a1ce824919b1cdfc93aeb0581a9
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.
