Merge "Harmonize notation of admonition blocks in documentation"

Documentation/access-control.txt

@@ -1092,7 +1092,8 @@ the same permission then this 'ALLOW' rule overrides the 'BLOCK' rule:
 In this case a user which is a member of the group 'Y' will still be allowed to
 push to 'refs/heads/*' even if it is a member of the group 'X'.
 
-NOTE: An 'ALLOW' rule overrides a 'BLOCK' rule only when both of them are
+[NOTE]
+An 'ALLOW' rule overrides a 'BLOCK' rule only when both of them are
 inside the same access section of the same project. An 'ALLOW' rule in a
 different access section of the same project or in any access section in an
 inheriting project cannot override a 'BLOCK' rule.

Documentation/cmd-apropos.txt

@@ -20,7 +20,8 @@ Any user who has configured an SSH key.
 == SCRIPTING
 This command is intended to be used in scripts.
 
-Note: this feature is only available if documentation index was built.
+[NOTE]
+This feature is only available if documentation index was built.
 
 == EXAMPLES
 

Documentation/cmd-review.txt

@@ -141,7 +141,7 @@ branch.
   can represent an external system like CI that does automated verification
   of the change. Comments with specific 'TAG' values can be filtered out in
   the web UI.
-  NOTE: To apply different tags on on different votes/comments multiple
+  Note that to apply different tags on on different votes/comments, multiple
   invocations of the SSH command are required.
 
 == ACCESS

Documentation/config-gerrit.txt

@@ -3108,7 +3108,8 @@ named `project/plugins/a` would be `CHERRY_PICK`.
   defaultSubmitType = CHERRY_PICK
 ----
 
-[NOTE] All properties are used from the matching repository configuration. In
+[NOTE]
+All properties are used from the matching repository configuration. In
 the previous example, all properties will be used from `project/plugins/\*`
 section and no properties will be inherited nor overridden from `project/*`.
 

Documentation/config-gitweb.txt

@@ -145,7 +145,8 @@ DirectoryIndex /cgi-bin/gitweb.cgi
 AllowOverride None
 ----
 
-*NOTE* This may have already been added by yum/apt-get. If that's the case, leave as
+[NOTE]
+This may have already been added by yum/apt-get. If that's the case, leave as
 is.
 
 ===== Restart the Apache Web Server

Documentation/config-labels.txt

@@ -332,7 +332,8 @@ the `branch` as:
 Then *only* changes in above branch scope of parent project and child
 projects will be affected by `Video-Qualify`.
 
-NOTE: The `branch` is independent from the branch scope defined in `access`
+[NOTE]
+The `branch` is independent from the branch scope defined in `access`
 parts in `project.config` file. That means from the UI a user can always
 assign permissions for that label on a branch, but this permission is then
 ignored if the label doesn't apply for that branch.

Documentation/config-login-register.txt

@@ -105,7 +105,8 @@ about our new key and can identify us by it.
   user@host:~$
 ----
 
-IMPORTANT: Please take note of the extra line-breaks introduced in the key above
+[IMPORTANT]
+Please take note of the extra line-breaks introduced in the key above
 for formatting purposes. Please be sure to copy and paste your key without
 line-breaks.
 

Documentation/dev-buck.txt

@@ -105,7 +105,8 @@ To build the Gerrit web application that includes GWT UI and PolyGerrit UI:
   buck build gerrit
 ----
 
-*Note: PolyGerrit UI may require additional tools (such as npm). Please read
+[NOTE]
+PolyGerrit UI may require additional tools (such as npm). Please read
 the polygerrit-ui/README.md for more info.
 
 The output executable WAR will be placed in:

Documentation/dev-inspector.txt

@@ -283,7 +283,8 @@ resulting from interactive work are logged to the console.
 == KNOWN ISSUES
 The Inspector does not yet recognize Google Guice bindings.
 
-IMPORTANT: Using the Inspector may void your warranty.
+[IMPORTANT]
+Using the Inspector may void your warranty.
 
 GERRIT
 ------

Documentation/dev-release-deploy-config.txt

@@ -142,7 +142,8 @@ deployable to the `gerrit-maven` storage bucket:
   </distributionManagement>
 ----
 
-NOTE: In case of JGit the `pom.xml` already contains a distributionManagement
+[NOTE]
+In case of JGit the `pom.xml` already contains a distributionManagement
 section.  Replace the existing distributionManagement section with this snippet
 in order to deploy the artifacts only in the gerrit-maven repository.
 

Documentation/dev-release.txt

@@ -1,12 +1,10 @@
 = Making a Gerrit Release
 
 [NOTE]
-========================================================================
 This document is meant primarily for Gerrit maintainers
 who have been given approval and submit status to the Gerrit
 projects.  Additionally, maintainers should be given owner
 status to the Gerrit web site.
-========================================================================
 
 To make a Gerrit release involves a great deal of complex
 tasks and it is easy to miss a step so this document should
@@ -34,16 +32,12 @@ need to undergo some stabilization before releasing the final release.
 * If needed create a Gerrit `RC1`
 
 [NOTE]
-========================================================================
 You may let in a few features to this release
-========================================================================
 
 * If needed create a Gerrit `RC2`
 
 [NOTE]
-========================================================================
 There should be no new features in this release, only bug fixes
-========================================================================
 
 * Finally create the `stable` release (no `RC`)
 

Documentation/install.txt

@@ -17,7 +17,8 @@ _ARCFOUR256_, and _ARCFOUR128_ can be enabled by downloading the _Java
 Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files_
 from Oracle and installing them into your JRE.
 
-NOTE: Installing JCE extensions is optional and export restrictions may apply.
+[NOTE]
+Installing JCE extensions is optional and export restrictions may apply.
 
 . Download the unlimited strength JCE policy files.
 +
@@ -82,7 +83,8 @@ own user account on the host system:
   java -jar gerrit.war init -d /path/to/your/gerrit_application_directory
 ----
 
-'Please note:' If you choose a location where your new user doesn't
+[NOTE]
+If you choose a location where your new user doesn't
 have any privileges, you may have to manually create the directory first and
 then give ownership of that location to the `'gerrit2'` user.
 

Documentation/prolog-change-facts.txt

@@ -4,7 +4,8 @@ Prior to invoking the `submit_rule(X)` query for a change, Gerrit initializes
 the Prolog engine with a set of facts (current data) about this change.
 The following table provides an overview of the provided facts.
 
-IMPORTANT: All the terms listed below are defined in the `gerrit` package. To use any
+[IMPORTANT]
+All the terms listed below are defined in the `gerrit` package. To use any
 of them we must use a qualified name like `gerrit:change_branch(X)`.
 
 .Prolog facts about the current change
@@ -97,7 +98,8 @@ the following table.
 
 |=============================================================================
 
-NOTE: for a complete list of built-in helpers read the `gerrit_common.pl` and
+[NOTE]
+For a complete list of built-in helpers read the `gerrit_common.pl` and
 all Java classes whose name matches `PRED_*.java` from Gerrit's source code.
 
 GERRIT

Documentation/prolog-cookbook.txt

@@ -17,7 +17,8 @@ define a set of criteria which must be fulfilled for a change to become
 submittable. For a change that is not submittable, the set of needed criteria
 is displayed in the Gerrit UI.
 
-NOTE: Loading and executing Prolog submit rules may be disabled by setting
+[NOTE]
+Loading and executing Prolog submit rules may be disabled by setting
 `rules.enable=false` in the Gerrit config file (see
 link:config-gerrit.html#_a_id_rules_a_section_rules[rules section])
 
@@ -73,7 +74,8 @@ For interactive testing and playing with Prolog, Gerrit provides the
 link:pgm-prolog-shell.html[prolog-shell] program which opens an interactive
 Prolog interpreter shell.
 
-NOTE: The interactive shell is just a prolog shell, it does not load
+[NOTE]
+The interactive shell is just a prolog shell, it does not load
 a gerrit server environment and thus is not intended for
 xref:TestingSubmitRules[testing submit rules].
 
@@ -160,10 +162,12 @@ be any other string (see examples below). The `status` is one of:
   could either be set or unset without ever influencing whether the change
   could be submitted.
 
-NOTE: For a change to be submittable all `label` terms contained in the returned
+[NOTE]
+For a change to be submittable all `label` terms contained in the returned
 `submit` term must have either `ok` or `may` status.
 
-IMPORTANT: Gerrit will let the Prolog engine continue searching for solutions of
+[IMPORTANT]
+Gerrit will let the Prolog engine continue searching for solutions of
 the `submit_rule(X)` query until it finds the first one where all labels in the
 return result have either status `ok` or `may` or there are no more solutions.
 If a solution where all labels have status `ok` is found then all previously
@@ -229,7 +233,8 @@ next `submit_filter` in the parent line. The value of the `Out` parameter
 of the top-most `submit_filter` is the final result of the submit rule that
 is used to decide whether a change is submittable or not.
 
-IMPORTANT: `submit_filter` is a mechanism for Gerrit administrators to implement
+[IMPORTANT]
+`submit_filter` is a mechanism for Gerrit administrators to implement
 and enforce submit rules that would apply to all projects while `submit_rule` is
 a mechanism for project owners to implement project specific submit rules.
 However, project owners who own several projects could also make use of
@@ -266,7 +271,8 @@ a `submit_filter` it is skipped.
 `submit_filter` in the `All-Projects` project. The value in `S` is the final
 value of the submit rule evaluation.
 
-NOTE: If `MyProject` doesn't define its own `submit_rule` Gerrit will invoke the
+[NOTE]
+If `MyProject` doesn't define its own `submit_rule` Gerrit will invoke the
 default implementation of submit rule that is named `gerrit:default_submit` and
 its result will be filtered as described above.
 
@@ -561,7 +567,8 @@ starts_with(L, []).
 starts_with([H|T1], [H|T2]) :- starts_with(T1, T2).
 ----
 
-NOTE: The `name/2` embedded predicate is used to convert a string symbol into a
+[NOTE]
+The `name/2` embedded predicate is used to convert a string symbol into a
 list of characters. A string `abc` is converted into a list of characters `[97,
 98, 99]`.  A double quoted string in Prolog is just a shortcut for creating a
 list of characters. `"abc"` is a shortcut for `[97, 98, 99]`. This is why we use

Documentation/user-upload.txt

@@ -184,11 +184,9 @@ option:
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%m=This_is_a_rebase_on_master
 ----
 
-.Note
-****
+[NOTE]
 git push refs parameter does not allow spaces.  Use the '_' character instead,
 it will then be applied as "This is a rebase on master".
-****
 
 [[review_labels]]
 Review labels can be applied to the change by using the `label` (or `l`)
@@ -291,8 +289,8 @@ For more about Change-Ids, see link:user-changeid.html[Change-Id Lines].
 [[manual_replacement_mapping]]
 ==== Manual Replacement Mapping
 
-.Note
-****
+[NOTE]
+--
 The remainder of this section describes a manual method of replacing
 changes by matching each commit name to an existing change number.
 End-users should instead prefer to use Change-Id lines in their
@@ -300,7 +298,7 @@ commit messages, as the process is then fully automated by Gerrit
 during normal uploads.
 
 See above for the preferred technique of replacing changes.
-****
+--
 
 To add an additional patch set to a change, replacing it with an
 updated version of the same logical modification, send the new