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
This commit is contained in:
Jonathan Nieder
committed by
David Pursehouse
David Pursehouse
parent
75b5190708
commit
5758f18ee5
@@ -210,8 +210,8 @@ Reference-level access control is also possible.
|
||||
|
||||
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 @@ particular regular expression flavor.
|
||||
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 @@ link:user-upload.html#push_create[Upload changes] page.
|
||||
|
||||
==== 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 @@ branch permissions, allowing the holder of both to create new branches
|
||||
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 @@ they are a member of, just like for any other user.
|
||||
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 @@ a new commit on their local system, so in practice they must also
|
||||
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 @@ must be also granted in addition to `Push Annotated Tag`.
|
||||
|
||||
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 @@ Suggested access rights to grant:
|
||||
|
||||
== 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.
|
||||
|
||||
|
||||
@@ -2576,8 +2576,8 @@ are specified in the link:#container[container section]:
|
||||
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.
|
||||
|
||||
|
||||
@@ -215,7 +215,7 @@ gitweb CGI.
|
||||
|
||||
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.
|
||||
|
||||
----
|
||||
|
||||
@@ -64,7 +64,7 @@ As you can see, there are several sections.
|
||||
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>>.
|
||||
|
||||
|
||||
@@ -1692,7 +1692,7 @@ class HelloServlet extends HttpServlet {
|
||||
----
|
||||
|
||||
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 @@ BranchWebLinks will appear in the branch list in the last column.
|
||||
== 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
|
||||
|
||||
@@ -9,32 +9,32 @@ In particular this error occurs:
|
||||
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].
|
||||
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ workflows for a project.
|
||||
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 @@ Access rights can be assigned on a concrete ref, e.g.
|
||||
`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
|
||||
|
||||
@@ -987,11 +987,11 @@ submit_type(cherry_pick).
|
||||
----
|
||||
|
||||
[[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 @@ 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
|
||||
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`
|
||||
|
||||
@@ -70,8 +70,8 @@ For more details, see link:cmd-hook-commit-msg.html[commit-msg].
|
||||
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:
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ to changes for the current user:
|
||||
== 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.
|
||||
|
||||
@@ -319,9 +319,9 @@ be rewritten.
|
||||
|
||||
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 @@ As Gerrit implements the entire SSH and Git server stack within its
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user