Fix formatting of example blocks

With the new stylesheet example blocks (delimited with ====) are
rendered as rather intrusive boxes with large padding in yellow
and grey.

This patch replaces the example blocks with simple code blocks
(delimited with ----) that better match the overall style of the
documentation.

Change-Id: Id95387cdb153332c2066e2d5e378697647dbca52
Signed-off-by: Michael Ochmann <michael.ochmann@sap.com>

Documentation/access-control.txt

@@ -421,10 +421,10 @@ draft patch sets of a change into public patch sets for review.
 To block push permission to `+refs/drafts/*+` the following permission rule can
 be configured:
 
-====
+----
   [access "refs/drafts/*"]
     push = block group Anonymous Users
-====
+----
 
 
 [[access_categories]]
@@ -637,15 +637,15 @@ This category permits users to push an annotated tag object into the
 project's repository.  Typically this would be done with a command line
 such as:
 
-====
+----
   git push ssh://USER@HOST:PORT/PROJECT tag v1.0
-====
+----
 
 Or:
 
-====
+----
   git push https://HOST/PROJECT tag v1.0
-====
+----
 
 Tags must be annotated (created with `git tag -a`), should exist in
 the `refs/tags/` namespace, and should be new.
@@ -677,15 +677,15 @@ This category permits users to push a PGP signed tag object into the
 project's repository.  Typically this would be done with a command
 line such as:
 
-====
+----
   git push ssh://USER@HOST:PORT/PROJECT tag v1.0
-====
+----
 
 Or:
 
-====
+----
   git push https://HOST/PROJECT tag v1.0
-====
+----
 
 Tags must be signed (created with `git tag -s`), should exist in the
 `refs/tags/` namespace, and should be new.
@@ -1069,10 +1069,10 @@ It is also possible to block label ranges.  To block a group 'X' from voting
 '-2' and '+2', but keep their existing voting permissions for the '-1..+1'
 range intact we would define:
 
-====
+----
   [access "refs/heads/*"]
     label-Code-Review = block -2..+2 group X
-====
+----
 
 The interpretation of the 'min..max' range in case of a blocking rule is: block
 every vote from '-INFINITE..min' and 'max..INFINITE'. For the example above it
@@ -1083,11 +1083,11 @@ means that the range '-1..+1' is not affected by this block.
 When an access section of a project contains a 'BLOCK' and an 'ALLOW' rule for
 the same permission then this 'ALLOW' rule overrides the 'BLOCK' rule:
 
-====
+----
   [access "refs/heads/*"]
     push = block group X
     push = group Y
-====
+----
 
 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'.
@@ -1108,22 +1108,22 @@ This requirement is quite common in a corporate deployment where
 reproducibility of a build must be guaranteed. To achieve that we block 'push'
 permission for the <<anonymous_users,'Anonymous Users'>> in "`All-Projects`":
 
-====
+----
   [access "refs/tags/*"]
     push = block group Anonymous Users
-====
+----
 
 By blocking the <<anonymous_users,'Anonymous Users'>> we effectively block
 everyone as everyone is a member of that group. Note that the permission to
 create a tag is still necessary. Assuming that only <<category_owner,project
 owners>> are allowed to create tags, we would extend the example above:
 
-====
+----
   [access "refs/tags/*"]
     push = block group Anonymous Users
     create = group Project Owners
     pushTag = group Project Owners
-====
+----
 
 
 ==== Let only a dedicated group vote in a special category
@@ -1136,11 +1136,11 @@ this category. We have to block everyone except the 'Release Engineers' to vote
 in this category and, of course, allow 'Release Engineers' to vote in that
 category. In the "`All-Projects`" we define the following rules:
 
-====
+----
   [access "refs/heads/stable*"]
     label-Release-Process = block -1..+1 group Anonymous Users
     label-Release-Process = -1..+1 group Release Engineers
-====
+----
 
 [[global_capabilities]]
 == Global Capabilities

Documentation/cmd-ban-commit.txt

@@ -44,10 +44,10 @@ This command is intended to be used in scripts.
 Ban commit `421919d015c062fd28901fe144a78a555d0b5984` from project
 `myproject`:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit ban-commit myproject \
 	421919d015c062fd28901fe144a78a555d0b5984
-====
+----
 
 GERRIT
 ------

Documentation/cmd-cherry-pick.txt

@@ -33,11 +33,11 @@ each commit message.
 To obtain the 'gerrit-cherry-pick' script use scp, curl or wget to
 copy it to your local system:
 
-====
+----
   $ scp -p -P 29418 john.doe@review.example.com:bin/gerrit-cherry-pick ~/bin/
 
   $ curl -Lo ~/bin/gerrit-cherry-pick http://review.example.com/tools/bin/gerrit-cherry-pick
-====
+----
 
 GERRIT
 ------

Documentation/cmd-create-account.txt

@@ -68,9 +68,9 @@ This most likely requires double quoting the value, for example
 Create a new batch/role access user account called `watcher` in
 the 'Non-Interactive Users' group.
 
-====
+----
 	$ cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit create-account --group "'Non-Interactive Users'" --ssh-key - watcher
-====
+----
 
 GERRIT
 ------

Documentation/cmd-create-branch.txt

@@ -39,9 +39,9 @@ This command is intended to be used in scripts.
 Create a new branch called 'newbranch' from the 'master' branch of
 the project 'myproject'.
 
-====
+----
     $ ssh -p 29418 review.example.com gerrit create-branch myproject newbranch master
-====
+----
 
 GERRIT
 ------

Documentation/cmd-create-group.txt

@@ -67,16 +67,16 @@ to the group.
 Create a new account group called `gerritdev` with two initial members
 `developer1` and `developer2`.  The group should be owned by itself:
 
-====
+----
 	$ ssh -p 29418 user@review.example.com gerrit create-group --member developer1 --member developer2 gerritdev
-====
+----
 
 Create a new account group called `Foo` owned by the `Foo-admin` group.
 Put `developer1` as the initial member and include group description:
 
-====
+----
 	$ ssh -p 29418 user@review.example.com gerrit create-group --owner Foo-admin --member developer1 --description "'Foo description'" Foo
-====
+----
 
 Note that it is necessary to quote the description twice.  The local
 shell needs double quotes around the value to ensure the single quotes

Documentation/cmd-create-project.txt

@@ -171,15 +171,15 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
 == EXAMPLES
 Create a new project called `tools/gerrit`:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit create-project tools/gerrit.git
-====
+----
 
 Create a new project with a description:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit create-project tool.git --description "'Tools used by build system'"
-====
+----
 
 Note that it is necessary to quote the description twice.  The local
 shell needs double quotes around the value to ensure the single quotes
@@ -190,9 +190,9 @@ the single quotes to delimit the value.
 If the replication plugin is installed, the plugin will attempt to
 perform remote repository creation by a Bourne shell script:
 
-====
+----
   mkdir -p '/base/project.git' && cd '/base/project.git' && git init --bare && git update-ref HEAD refs/heads/master
-====
+----
 
 For this to work successfully the remote system must be able to run
 arbitrary shell scripts, and must have `git` in the user's PATH

Documentation/cmd-flush-caches.txt

@@ -57,7 +57,7 @@ This command is intended to be used in scripts.
 == EXAMPLES
 List caches available for flushing:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit flush-caches --list
 	accounts
 	accounts_byemail
@@ -68,32 +68,32 @@ List caches available for flushing:
 	projects
 	sshkeys
 	web_sessions
-====
+----
 
 Flush all caches known to the server, forcing them to recompute:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit flush-caches --all
-====
+----
 
 or
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit flush-caches
-====
+----
 
 Flush only the "sshkeys" cache, after manually editing an SSH key
 for a user:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys
-====
+----
 
 Flush "web_sessions", forcing all users to sign-in again:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit flush-caches --cache web_sessions
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-gc.txt

@@ -53,7 +53,7 @@ This command is intended to be used in scripts.
 
 Run the Git garbage collection for the projects 'myProject' and
 'yourProject':
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit gc myProject yourProject
 	collecting garbage for "myProject":
 	...
@@ -62,12 +62,12 @@ Run the Git garbage collection for the projects 'myProject' and
 	collecting garbage for "yourProject":
 	...
 	done.
-=====
+----
 
 Run the Git garbage collection for all projects:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit gc --all
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-gsql.txt

@@ -41,7 +41,7 @@ JSON_SINGLE.
 == EXAMPLES
 To manually correct a user's SSH user name:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit gsql
 	Welcome to Gerrit Code Review v2.0.25
 	(PostgreSQL 8.3.8)
@@ -54,7 +54,7 @@ To manually correct a user's SSH user name:
 	Bye
 
 	$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys --cache accounts
-====
+----
 
 GERRIT
 ------

Documentation/cmd-hook-commit-msg.txt

@@ -63,26 +63,26 @@ it to your local system from your Gerrit server.
 
 You can use either of the below commands:
 
-====
+----
   $ scp -p -P 29418 <your username>@<your Gerrit review server>:hooks/commit-msg <local path to your git>/.git/hooks/
 
   $ curl -Lo <local path to your git>/.git/hooks/commit-msg <your Gerrit http URL>/tools/hooks/commit-msg
-====
+----
 
 A specific example of this might look something like this:
 
 .Example
-====
+----
   $ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg ~/duhproject/.git/hooks/
 
   $ curl -Lo ~/duhproject/.git/hooks/commit-msg http://review.example.com/tools/hooks/commit-msg
-====
+----
 
 Make sure the hook file is executable:
 
-====
+----
   $ chmod u+x ~/duhproject/.git/hooks/commit-msg
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-index-changes.txt

@@ -29,9 +29,9 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Index changes with legacy ID numbers 1 and 2.
 
-====
+----
     $ ssh -p 29418 user@review.example.com gerrit index changes 1 2
-====
+----
 
 GERRIT
 ------

Documentation/cmd-index.txt

@@ -7,11 +7,13 @@ from Gerrit's daemon, and then executed on the client system.
 
 To download a client command or hook, use scp or an http client:
 
+----
   $ scp -p -P 29418 john.doe@review.example.com:bin/gerrit-cherry-pick ~/bin/
   $ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg .git/hooks/
 
   $ curl -Lo ~/bin/gerrit-cherry-pick http://review.example.com/tools/bin/gerrit-cherry-pick
   $ curl -Lo .git/hooks/commit-msg http://review.example.com/tools/hooks/commit-msg
+----
 
 For more details on how to determine the correct SSH port number,
 see link:user-upload.html#test_ssh[Testing Your SSH Connection].
@@ -38,7 +40,9 @@ several other commands over its internal SSH daemon.  As Gerrit does
 not provide an interactive shell, the commands must be triggered
 from an ssh client, for example:
 
+----
   $ ssh -p 29418 review.example.com gerrit ls-projects
+----
 
 For more details on how to determine the correct SSH port number,
 see link:user-upload.html#test_ssh[Testing Your SSH Connection].

Documentation/cmd-logging-ls-level.txt

@@ -26,15 +26,15 @@ Caller must have the ADMINISTRATE_SERVER capability.
 == Examples
 
 View the logging level of the loggers in the package com.google:
-=====
+----
     $ssh -p 29418 review.example.com gerrit logging ls-level \
      com.google.
-=====
+----
 
 View the logging level of every logger
-=====
+----
     $ssh -p 29418 review.example.com gerrit logging ls-level
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-logging-set-level.txt

@@ -33,16 +33,16 @@ Caller must have the ADMINISTRATE_SERVER capability.
 == Examples
 
 Change the logging level of the loggers in the package com.google to DEBUG.
-=====
+----
     $ssh -p 29418 review.example.com gerrit logging set-level \
      debug com.google.
-=====
+----
 
 Reset the logging level of every logger to what they were at deployment time.
-=====
+----
     $ssh -p 29418 review.example.com gerrit logging set-level \
      reset
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-ls-groups.txt

@@ -87,55 +87,55 @@ nonexistent group, the owner group name field will read `n/a`.
 == EXAMPLES
 
 List visible groups:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-groups
 	Administrators
 	Anonymous Users
 	MyProject_Committers
 	Project Owners
 	Registered Users
-=====
+----
 
 List all groups for which any permission is set for the project
 "MyProject":
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-groups --project MyProject
 	MyProject_Committers
 	Project Owners
 	Registered Users
-=====
+----
 
 List all groups which are owned by the calling user:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-groups --owned
 	MyProject_Committers
 	MyProject_Verifiers
-=====
+----
 
 Check if the calling user owns the group `MyProject_Committers`. If
 `MyProject_Committers` is returned the calling user owns this group.
 If the result is empty, the calling user doesn't own the group.
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-groups --owned -q MyProject_Committers
 	MyProject_Committers
-=====
+----
 
 Extract the UUID of the 'Administrators' group:
 
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-groups -v | awk '-F\t' '$1 == "Administrators" {print $2}'
 	ad463411db3eec4e1efb0d73f55183c1db2fd82a
-=====
+----
 
 Extract and expand the multi-line description of the 'Administrators'
 group:
 
-=====
+----
 	$ printf "$(ssh -p 29418 review.example.com gerrit ls-groups -v | awk '-F\t' '$1 == "Administrators" {print $3}')\n"
 	This is a
 	multi-line
 	description.
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-ls-members.txt

@@ -39,19 +39,19 @@ the output.
 == EXAMPLES
 
 List members of the Administrators group:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-members Administrators
 	id      username  full name    email
 	100000  jim     Jim Bob somebody@example.com
 	100001  johnny  John Smith      n/a
 	100002  mrnoname        n/a     someoneelse@example.com
-=====
+----
 
 List members of a non-existent group:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-members BadlySpelledGroup
 	Group not found or not visible
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-ls-projects.txt

@@ -114,7 +114,7 @@ by the client in the request headers.
 == EXAMPLES
 
 List visible projects:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-projects
 	platform/manifest
 	tools/gerrit
@@ -128,16 +128,16 @@ List visible projects:
 	$ curl http://review.example.com/projects/tools/
 	tools/gerrit
 	tools/gwtorm
-=====
+----
 
 Clone any project visible to the user:
-====
+----
 	for p in `ssh -p 29418 review.example.com gerrit ls-projects`
 	do
 	  mkdir -p `dirname "$p"`
 	  git clone --bare "ssh://review.example.com:29418/$p.git" "$p.git"
 	done
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-ls-user-refs.txt

@@ -41,9 +41,9 @@ Administrators
 == EXAMPLES
 
 List visible refs for the user "mr.developer" in project "gerrit"
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit ls-user-refs -p gerrit -u mr.developer
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-plugin-enable.txt

@@ -31,9 +31,9 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Enable a plugin:
 
-====
+----
 	ssh -p 29418 localhost gerrit plugin enable my-plugin
-====
+----
 
 GERRIT
 ------

Documentation/cmd-plugin-install.txt

@@ -45,31 +45,31 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Install a plugin from an absolute file path on the server's host:
 
-====
+----
 	ssh -p 29418 localhost gerrit plugin install -n name.jar \
 	  $(pwd)/my-plugin.jar
-====
+----
 
 Install a WebUi plugin from an absolute file path on the server's host:
 
-====
+----
   ssh -p 29418 localhost gerrit plugin install -n name.js \
     $(pwd)/my-webui-plugin.js
-====
+----
 
 Install a plugin from an HTTP site:
 
-====
+----
 	ssh -p 29418 localhost gerrit plugin install -n name.jar \
 	  http://build-server/output/our-plugin
-====
+----
 
 Install a plugin from piped input:
 
-====
+----
 	ssh -p 29418 localhost gerrit plugin install -n name.jar \
 	  - <target/name-0.1.jar
-====
+----
 
 GERRIT
 ------

Documentation/cmd-plugin-reload.txt

@@ -35,9 +35,9 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Reload a plugin:
 
-====
+----
 	ssh -p 29418 localhost gerrit plugin reload my-plugin
-====
+----
 
 GERRIT
 ------

Documentation/cmd-plugin-remove.txt

@@ -32,9 +32,9 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Disable a plugin:
 
-====
+----
 	ssh -p 29418 localhost gerrit plugin remove my-plugin
-====
+----
 
 GERRIT
 ------

Documentation/cmd-query.txt

@@ -116,20 +116,20 @@ This command is intended to be used in scripts.
 == EXAMPLES
 
 Find the 2 most recent open changes in the tools/gerrit project:
-====
+----
   $ ssh -p 29418 review.example.com gerrit query --format=JSON status:open project:tools/gerrit limit:2
   {"project":"tools/gerrit", ...}
   {"project":"tools/gerrit", ...}
   {"type":"stats","rowCount":2,"runningTimeMilliseconds:15}
-====
+----
 
 Skip number of changes:
-====
+----
   $ ssh -p 29418 review.example.com gerrit query --format=JSON --start 42 status:open project:tools/gerrit limit:2
   {"project":"tools/gerrit", ...}
   {"project":"tools/gerrit", ...}
   {"type":"stats","rowCount":1,"runningTimeMilliseconds:15}
-====
+----
 
 
 == SCHEMA

Documentation/cmd-receive-pack.txt

@@ -42,25 +42,25 @@ Any user who has configured an SSH key.
 == EXAMPLES
 
 Send a review for a change on the master branch to charlie@example.com:
-=====
+----
 	git push ssh://review.example.com:29418/project HEAD:refs/for/master%r=charlie@example.com
-=====
+----
 
 Send reviews, but tagging them with the topic name 'bug42':
-=====
+----
 	git push ssh://review.example.com:29418/project HEAD:refs/for/master%r=charlie@example.com,topic=bug42
-=====
+----
 
 Also CC two other parties:
-=====
+----
 	git push ssh://review.example.com:29418/project HEAD:refs/for/master%r=charlie@example.com,cc=alice@example.com,cc=bob@example.com
-=====
+----
 
 Configure a push macro to perform the last action:
-====
+----
 	git config remote.charlie.url ssh://review.example.com:29418/project
 	git config remote.charlie.push HEAD:refs/for/master%r=charlie@example.com,cc=alice@example.com,cc=bob@example.com
-====
+----
 
 afterwards `.git/config` contains the following:
 ----
@@ -71,9 +71,9 @@ afterwards `.git/config` contains the following:
 
 and now sending a new change for review to charlie, CC'ing both
 alice and bob is much easier:
-====
+----
 	git push charlie
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-rename-group.txt

@@ -31,9 +31,9 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Rename the group "MyGroup" to "MyCommitters".
 
-====
+----
 	$ ssh -p 29418 user@review.example.com gerrit rename-group MyGroup MyCommitters
-====
+----
 
 GERRIT
 ------

Documentation/cmd-review.txt

@@ -153,37 +153,37 @@ This command is intended to be used in scripts.
 == EXAMPLES
 
 Approve the change with commit c0ff33 as "Verified +1"
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit review --verified +1 c0ff33
-=====
+----
 
 Vote on the project specific label "mylabel":
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit review --label mylabel=+1 c0ff33
-=====
+----
 
 Append the message "Build Successful". Notice two levels of quoting is
 required, one for the local shell, and another for the argument parser
 inside the Gerrit server:
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit review -m '"Build Successful"' c0ff33
-=====
+----
 
 Mark the unmerged commits both "Verified +1" and "Code-Review +2" and
 submit them for merging:
-====
+----
   $ ssh -p 29418 review.example.com gerrit review \
     --verified +1 \
     --code-review +2 \
     --submit \
     --project this/project \
     $(git rev-list origin/master..HEAD)
-====
+----
 
 Abandon an active change:
-====
+----
   $ ssh -p 29418 review.example.com gerrit review --abandon c0ff33
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-set-account.txt

@@ -102,9 +102,9 @@ This most likely requires double quoting the value, for example
 == EXAMPLES
 Add an email and SSH key to `watcher`'s account:
 
-====
+----
     $ cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit set-account --add-ssh-key - --add-email mail@example.com watcher
-====
+----
 
 GERRIT
 ------

Documentation/cmd-set-head.txt

@@ -34,9 +34,9 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Change HEAD of project `example` to `stable-2.11` branch:
 
-====
+----
     $ ssh -p 29418 review.example.com gerrit set-head example --new-head stable-2.11
-====
+----
 
 GERRIT
 ------

Documentation/cmd-set-members.txt

@@ -58,18 +58,18 @@ This command is intended to be used in scripts.
 
 Add alice and bob, but remove eve from the groups my-committers and
 my-verifiers.
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit set-members \
 	  -a alice@example.com -a bob@example.com \
 	  -r eve@example.com my-committers my-verifiers
-=====
+----
 
 Include the group my-friends into the group my-committers, but
 exclude the included group my-testers from the group my-committers.
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit set-members \
 	  -i my-friends -e my-testers my-committers
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-set-project-parent.txt

@@ -46,16 +46,16 @@ This command is intended to be used in scripts.
 == EXAMPLES
 Configure `kernel/omap` to inherit permissions from `kernel/common`:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit set-project-parent --parent kernel/common kernel/omap
-====
+----
 
 Reparent all children of `myParent` to `myOtherParent`:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit set-project-parent \
 	  --children-of myParent --parent myOtherParent
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-set-project.txt

@@ -103,10 +103,10 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
 Change project `example` to be hidden, require change id, don't use content merge
 and use 'merge if necessary' as merge strategy:
 
-====
+----
     $ ssh -p 29418 review.example.com gerrit set-project example --submit-type MERGE_IF_NECESSARY\
     --change-id true --content-merge false --project-state HIDDEN
-====
+----
 
 GERRIT
 ------

Documentation/cmd-set-reviewers.txt

@@ -55,27 +55,27 @@ This command is intended to be used in scripts.
 == EXAMPLES
 
 Add reviewers alice and bob, but remove eve from change Iac6b2ac2.
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit set-reviewers \
 	  -a alice@example.com -a bob@example.com \
 	  -r eve@example.com \
 	  Iac6b2ac2
-=====
+----
 
 Add reviewer elvis to old-style change id 1935 specifying that the change is in project "graceland"
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit set-reviewers \
 	  --project graceland \
 	  -a elvis@example.com \
 	  1935
-=====
+----
 
 Add all project owners as reviewers to change Iac6b2ac2.
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit set-reviewers \
 	  -a "'Project Owners'" \
 	  Iac6b2ac2
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-show-caches.txt

@@ -51,7 +51,7 @@ Intended for interactive use only.
 
 == EXAMPLES
 
-====
+----
   $ ssh -p 29418 review.example.com gerrit show-caches
   Gerrit Code Review        2.9                       now   11:14:13   CEST
                                                    uptime    6 days 20 hrs
@@ -90,7 +90,7 @@ Intended for interactive use only.
            107 open files
 
   Threads: 4 CPUs available, 371 threads
-====
+----
 
 == SEE ALSO
 

Documentation/cmd-show-connections.txt

@@ -62,22 +62,22 @@ Remote Host::
 == EXAMPLES
 
 With reverse DNS lookup (default):
-====
+----
 	$ ssh -p 29418 review.example.com gerrit show-connections
 	Session     Start     Idle   User            Remote Host
 	--------------------------------------------------------------
 	3abf31e6 20:09:02 00:00:00  jdoe            jdoe-desktop.example.com
 	--
-====
+----
 
 Without reverse DNS lookup:
-====
+----
 	$ ssh -p 29418 review.example.com gerrit show-connections -n
 	Session     Start     Idle   User            Remote Host
 	--------------------------------------------------------------
 	3abf31e6 20:09:02 00:00:00  a/1001240       10.0.0.1
 	--
-====
+----
 
 GERRIT
 ------

Documentation/cmd-show-queue.txt

@@ -70,7 +70,7 @@ The following queue contains two tasks scheduled to replicate the
 `tools/gerrit.git` project to two different remote systems, `dst1`
 and `dst2`:
 
-====
+----
 	$ ssh -p 29418 review.example.com gerrit show-queue
 	Task     State                 Command
 	------------------------------------------------------------------------------
@@ -78,7 +78,7 @@ and `dst2`:
 	9ad09d27 14:31:25.434          mirror dst2:/var/cache/tools/gerrit.git
 	------------------------------------------------------------------------------
 	  2 tasks
-====
+----
 
 GERRIT
 ------

Documentation/cmd-stream-events.txt

@@ -37,18 +37,18 @@ This command is intended to be used in scripts.
 
 == EXAMPLES
 
-====
+----
   $ ssh -p 29418 review.example.com gerrit stream-events
   {"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}
   {"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}
-====
+----
 
 Only subscribe to specific event types:
 
-====
+----
   $ ssh -p 29418 review.example.com gerrit stream-events \
       -s draft-published -s patchset-created -s ref-replicated
-====
+----
 
 == SCHEMA
 The JSON messages consist of nested objects referencing the *change*,

Documentation/cmd-suexec.txt

@@ -48,7 +48,7 @@ This command is intended to be used in scripts.
 == EXAMPLES
 
 Approve the change with commit c0ff33 as "Verified +1" as user bob@example.com
-=====
+----
   $ sudo -u gerrit ssh -p 29418 \
     -i site_path/etc/ssh_host_rsa_key \
     "Gerrit Code Review@localhost" \
@@ -56,7 +56,7 @@ Approve the change with commit c0ff33 as "Verified +1" as user bob@example.com
     --as bob@example.com \
     -- \
     gerrit approve --verified +1 c0ff33
-=====
+----
 
 GERRIT
 ------

Documentation/cmd-test-submit-rule.txt

@@ -28,7 +28,7 @@ Can be used by anyone that has permission to read the specified changeset.
 == EXAMPLES
 
 Test submit_rule from stdin and return the results as JSON.
-====
+----
  cat rules.pl | ssh -p 29418 review.example.com gerrit test-submit rule -s I78f2c6673db24e4e92ed32f604c960dc952437d9
  [
    {
@@ -38,10 +38,10 @@ Test submit_rule from stdin and return the results as JSON.
      }
    }
  ]
-====
+----
 
 Test the active submit_rule from the refs/meta/config branch, ignoring filters in the project parents.
-====
+----
  $ ssh -p 29418 review.example.com gerrit test-submit rule I78f2c6673db24e4e92ed32f604c960dc952437d9 --no-filters
  [
    {
@@ -52,7 +52,7 @@ Test the active submit_rule from the refs/meta/config branch, ignoring filters i
      }
    }
  ]
-====
+----
 
 == SCRIPTING
 Can be used either interactively for testing new prolog submit rules, or from a script to check the submit status of a change.

Documentation/cmd-test-submit-type.txt

@@ -28,16 +28,16 @@ Can be used by anyone that has permission to read the specified change.
 == EXAMPLES
 
 Test submit_type from stdin and return the submit type.
-====
+----
  cat rules.pl | ssh -p 29418 review.example.com gerrit test-submit type -s I78f2c6673db24e4e92ed32f604c960dc952437d9
  "MERGE_IF_NECESSARY"
-====
+----
 
 Test the active submit_type from the refs/meta/config branch, ignoring filters in the project parents.
-====
+----
  $ ssh -p 29418 review.example.com gerrit test-submit type I78f2c6673db24e4e92ed32f604c960dc952437d9 --no-filters
  "MERGE_IF_NECESSARY"
-====
+----
 
 == SCRIPTING
 Can be used either interactively for testing new prolog submit type, or from a script to check the submit type of a change.

Documentation/cmd-version.txt

@@ -33,10 +33,10 @@ This command is intended to be used in scripts.
 
 == EXAMPLES
 
-=====
+----
 	$ ssh -p 29418 review.example.com gerrit version
 	gerrit version 2.4.2
-=====
+----
 
 GERRIT
 ------

Documentation/config-cla.txt

@@ -12,27 +12,27 @@ permissions work.
 
 To retrieve the `project.config` file, initialize a temporary Git
 repository to edit the configuration:
-====
+----
   mkdir cfg_dir
   cd cfg_dir
   git init
-====
+----
 
 Download the existing configuration from Gerrit:
-====
+----
   git fetch ssh://localhost:29418/All-Projects refs/meta/config
   git checkout FETCH_HEAD
-====
+----
 
 Contributor agreements are defined as contributor-agreement sections in
 `project.config`:
-====
+----
   [contributor-agreement "Individual"]
     description = If you are going to be contributing code on your own, this is the one you want. You can sign this one online.
     agreementUrl = static/cla_individual.html
     autoVerify = group CLA Accepted - Individual
     accepted = group CLA Accepted - Individual
-====
+----
 
 Each `contributor-agreement` section within the `project.config` file must
 have a unique name. The section name will appear in the web UI.
@@ -41,10 +41,10 @@ If not already present, add the UUID of the groups used in the
 `autoVerify` and `accepted` variables in the groups file.
 
 Commit the configuration change, and push it back:
-====
+----
   git commit -a -m "Add Individual contributor agreement"
   git push ssh://localhost:29418/All-Projects HEAD:refs/meta/config
-====
+----
 
 [[contributor-agreement.name.description]]contributor-agreement.<name>.description::
 +

Documentation/config-gitweb.txt

@@ -16,10 +16,10 @@ installed CGI.  This defaults to `/usr/lib/cgi-bin/gitweb.cgi`,
 which is a common installation path for the 'gitweb' package on
 Linux distributions.
 
-====
+----
   git config --file $site_path/etc/gerrit.config gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
   git config --file $site_path/etc/gerrit.config --unset gitweb.url
-====
+----
 
 Alternatively, if Gerrit is served behind reverse proxy, it can
 generate different URLs for gitweb's links (they need to be
@@ -27,10 +27,10 @@ rewritten to `<gerrit>/gitweb?args` on the web server). This allows
 for serving gitweb under a different URL than the Gerrit instance.
 To enable this feature, set both: `gitweb.cgi` and `gitweb.url`.
 
-====
+----
   git config --file $site_path/etc/gerrit.config gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
   git config --file $site_path/etc/gerrit.config gitweb.url /pretty/path/to/gitweb
-====
+----
 
 After updating `'$site_path'/etc/gerrit.config`, the Gerrit server must
 be restarted and clients must reload the host page to see the change.
@@ -76,15 +76,15 @@ provides configuration parameters for integration with gitweb.
 
 On Ubuntu:
 
-====
+----
-  sudo apt-get install gitweb
+  $ sudo apt-get install gitweb
-====
+----
 
 With Yum:
 
-====
+----
   $ yum install gitweb
-====
+----
 
 ===== Configure Gitweb
 
@@ -124,16 +124,16 @@ $favicon = "git-favicon.png";
 
 Link gitweb to `/var/www/gitweb`, check `/etc/gitweb.conf` if unsure of paths:
 
-====
+----
   $ sudo ln -s /usr/share/gitweb /var/www/gitweb
-====
+----
 
 Add the gitweb directory to the Apache configuration by creating a "gitweb"
 file inside the Apache conf.d directory:
 
-====
+----
   $ touch /etc/apache/conf.d/gitweb
-====
+----
 
 Add the following to /etc/apache/conf.d/gitweb:
 
@@ -150,9 +150,9 @@ is.
 
 ===== Restart the Apache Web Server
 
-====
+----
-$ sudo /etc/init.d/apache2 restart
+  $ sudo /etc/init.d/apache2 restart
-====
+----
 
 Now you should be able to view your repository projects online:
 
@@ -182,9 +182,9 @@ is broken.. The link:http://groups.google.com/group/msysgit/browse_thread/thread
 verify by checking for perl modules. From an msys console, execute the
 following to check:
 
-====
+----
 $ perl -mCGI -mEncode -mFcntl -mFile::Find -mFile::Basename -e ""
-====
+----
 
 You may encounter the following exception:
 

Documentation/config-labels.txt

@@ -90,13 +90,13 @@ expect to use the Verified label to vote on a change after running.
 Administrators can install the Verified label by adding the following
 text to `project.config`:
 
-====
+----
   [label "Verified"]
       function = MaxWithBlock
       value = -1 Fails
       value =  0 No score
       value = +1 Verified
-====
+----
 
 The range of values is:
 
@@ -323,11 +323,11 @@ Label's applicable scope can be branch specific via configuration.
 E.g. create a label `Video-Qualify` on parent project and configure
 the `branch` as:
 
-====
+----
   [label "Video-Qualify"]
       branch = refs/heads/video-1.0/*
       branch = refs/heads/video-1.1/Kino
-====
+----
 
 Then *only* changes in above branch scope of parent project and child
 projects will be affected by `Video-Qualify`.
@@ -343,13 +343,13 @@ ignored if the label doesn't apply for that branch.
 To define a new 3-valued category that behaves exactly like `Verified`,
 but has different names/labels:
 
-====
+----
   [label "Copyright-Check"]
       function = MaxWithBlock
       value = -1 Do not have copyright
       value =  0 No score
       value = +1 Copyright clear
-====
+----
 
 The new column will appear at the end of the table, and `-1 Do not have
 copyright` will block submit, while `+1 Copyright clear` is required to
@@ -360,7 +360,7 @@ enable submit.
 This example attempts to describe how a label default value works with the
 user permissions.  Assume the configuration below.
 
-====
+----
   [access "refs/heads/*"]
       label-Snarky-Review = -3..+3 group Administrators
       label-Snarky-Review = -2..+2 group Project Owners
@@ -374,7 +374,7 @@ user permissions.  Assume the configuration below.
       value = +2 Hmm, this is pretty nice
       value = +3 Ohh, hell yes!
       defaultValue = -3
-====
+----
 
 Upon clicking the Reply button:
 
@@ -386,7 +386,7 @@ Upon clicking the Reply button:
 
 This example shows how a label can be configured to have a standard patch set lock.
 
-====
+----
   [access "refs/heads/*"]
       label-Patch-Set-Lock = +0..+1 group Administrators
   [label "Patch-Set-Lock"]
@@ -394,7 +394,7 @@ This example shows how a label can be configured to have a standard patch set lo
       value =  0 Patch Set Unlocked
       value = +1 Patch Set Locked
       defaultValue = 0
-====
+----
 
 GERRIT
 ------

Documentation/config-sso.txt

@@ -10,9 +10,9 @@ By default a new Gerrit installation relies upon OpenID to perform
 user authentication services.  To enable OpenID, the auth.type
 setting should be `OpenID`:
 
-====
+----
   git config --file $site_path/etc/gerrit.config auth.type OpenID
-====
+----
 
 As this is the default setting there is nothing required from the
 site administrator to make use of the OpenID authentication services.
@@ -24,9 +24,9 @@ buffer size parameter, due to very long header lines.
 Add the following to `$JETTY_HOME/etc/jetty.xml` under
 `org.mortbay.jetty.nio.SelectChannelConnector`:
 
-====
+----
   <Set name="headerBufferSize">16384</Set>
-====
+----
 
 In order to use permissions beyond those granted to the
 `Anonymous Users` and `Registered Users` groups, an account
@@ -44,9 +44,9 @@ will match any OpenID provider on the Internet:
 * `https://` -- trust all OpenID providers using the HTTPS protocol
 
 To trust only Yahoo!:
-====
+----
   git config --file $site_path/etc/gerrit.config auth.trustedOpenID https://me.yahoo.com
-====
+----
 
 === Database Schema
 
@@ -100,11 +100,11 @@ all requests have already been authenticated.  The "Sign In" and
 
 To enable this form of authentication:
 
-====
+----
   git config --file $site_path/etc/gerrit.config auth.type HTTP
   git config --file $site_path/etc/gerrit.config --unset auth.httpHeader
   git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com'
-====
+----
 
 The auth.type must always be HTTP, indicating the user identity
 will be obtained from the HTTP authorization data.
@@ -124,14 +124,14 @@ Apache server will be handling user authentication, a configuration
 such as the following is recommended to ensure Apache performs the
 authentication at the proper time:
 
-====
+----
   <Location "/login/">
     AuthType Basic
     AuthName "Gerrit Code Review"
     Require valid-user
     ...
   </Location>
-====
+----
 
 === Database Schema
 
@@ -161,11 +161,11 @@ all requests have already been authenticated.  The "Sign In" and
 
 To enable this form of authentication:
 
-====
+----
   git config --file $site_path/etc/gerrit.config auth.type HTTP
   git config --file $site_path/etc/gerrit.config auth.httpHeader SM_USER
   git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com'
-====
+----
 
 The auth.type must always be HTTP, indicating the user identity
 will be obtained from the HTTP authorization data.
@@ -186,9 +186,9 @@ buffer size parameter, due to very long header lines.
 Add the following to `$JETTY_HOME/etc/jetty.xml` under
 `org.mortbay.jetty.nio.SelectChannelConnector`:
 
-====
+----
   <Set name="headerBufferSize">16384</Set>
-====
+----
 
 
 === Database Schema

Documentation/config-themes.txt

@@ -88,7 +88,7 @@ reference the new image path.
 To connect Gerrit to Google Analytics add the following to your
 `GerritSiteFooter.html`:
 
-====
+----
   <div>
   <!-- standard analytics code -->
     <script type="text/javascript">
@@ -110,7 +110,7 @@ To connect Gerrit to Google Analytics add the following to your
     };
   </script>
   </div>
-====
+----
 
 Please consult the Google Analytics documentation for the correct
 setup code (the first two script tags).  The above is shown only

Documentation/dev-plugins.txt

@@ -90,11 +90,11 @@ gerrit-plugin-api.jar::
 Plugins may provide optional description information with standard
 manifest fields:
 
-====
+----
   Implementation-Title: Example plugin showing examples
   Implementation-Version: 1.0
   Implementation-Vendor: Example, Inc.
-====
+----
 
 === ApiType
 
@@ -104,9 +104,9 @@ internals. If no `Gerrit-ApiType` is specified the stable `extension`
 API will be assumed. This may cause ClassNotFoundExceptions when
 loading a plugin that needs the plugin API.
 
-====
+----
   Gerrit-ApiType: plugin
-====
+----
 
 === Explicit Registration
 
@@ -119,20 +119,20 @@ server (if enabled). If no modules are named automatic registration
 will be performed by scanning all classes in the plugin JAR for
 `@Listen` and `@Export("")` annotations.
 
-====
+----
   Gerrit-Module:     tld.example.project.CoreModuleClassName
   Gerrit-SshModule:  tld.example.project.SshModuleClassName
   Gerrit-HttpModule: tld.example.project.HttpModuleClassName
-====
+----
 
 [[plugin_name]]
 === Plugin Name
 
 A plugin can optionally provide its own plugin name.
 
-====
+----
   Gerrit-PluginName: replication
-====
+----
 
 This is useful for plugins that contribute plugin-owned capabilities that
 are stored in the `project.config` file. Another use case is to be able to put
@@ -216,9 +216,9 @@ to be `restart`. Otherwise the preferred method of `reload` will
 be used, as it enables the server to hot-patch an updated plugin
 with no down time.
 
-====
+----
   Gerrit-ReloadMode: restart
-====
+----
 
 In either mode ('restart' or 'reload') any plugin or extension can
 be updated without restarting the Gerrit server. The difference is
@@ -259,9 +259,9 @@ For instance plugins to integrate Jira issues to Gerrit changes may
 contribute their own "init step" to allow configuring the Jira URL,
 credentials and possibly verify connectivity to validate them.
 
-====
+----
   Gerrit-InitStep: tld.example.project.MyInitStep
-====
+----
 
 MyInitStep needs to follow the standard Gerrit InitStep syntax
 and behavior: writing to the console using the injected ConsoleUI
@@ -1355,13 +1355,13 @@ A new button is placed on the popup dialog to actually send the request.
 Every `UiAction` exposes a REST API endpoint. The endpoint from the example above
 can be accessed from any REST client, i. e.:
 
-====
+----
   curl -X POST -H "Content-Type: application/json" \
     -d '{message: "François", french: true}' \
     --digest --user joe:secret \
     http://host:port/a/changes/1/revisions/1/cookbook~say-hello
   "Bonjour François from change 1, patch set 1!"
-====
+----
 
 A special case is to bind an endpoint without a view name.  This is
 particularly useful for `DELETE` requests:

Documentation/dev-release-subproject.txt

@@ -6,9 +6,9 @@
 * Build the latest snapshot and install it into the local Maven
 repository:
 +
-====
+----
   mvn clean install
-====
+----
 
 * Test Gerrit with this snapshot locally
 
@@ -27,9 +27,9 @@ Configuration for Subprojects in `pom.xml`]
 
 * Deploy the new snapshot:
 +
-====
+----
   mvn deploy
-====
+----
 
 * Change the `id`, `bin_sha1`, and `src_sha1` values in the `maven_jar`
 for the subproject in `/lib/BUCK` to the `SNAPSHOT` version.
@@ -50,15 +50,15 @@ below)
 
 * Create the Release Tag
 +
-====
+----
- git tag -a -m "prolog-cafe 1.3" v1.3
+  git tag -a -m "prolog-cafe 1.3" v1.3
-====
+----
 
 * Build and install into local Maven repository:
 +
-====
+----
   mvn clean install
-====
+----
 
 
 [[publish-release]]
@@ -72,18 +72,18 @@ link:dev-release-deploy-config.html#deploy-configuration-subprojects[subprojects
 
 * Deploy the new release:
 +
-====
+----
   mvn deploy
-====
+----
 
 * Push the pom change(s) to the project's repository
 `refs/for/<master|stable>`
 
 * Push the Release Tag
 +
-====
+----
   git push gerrit-review refs/tags/v1.3:refs/tags/v1.3
-====
+----
 
 
 GERRIT

Documentation/dev-release.txt

@@ -358,20 +358,15 @@ homepage project] to change the version numbers to the new version.
 [[update-issues]]
 ==== Update the Issues
 
-====
+Update the issues by hand. There is no script for this.
- How do the issues get updated?  Do you run a script to do
- this?  When do you do it, after the final 2.5 is released?
-====
-
-By hand.
 
 Our current process is an issue should be updated to say `Status =
 Submitted, FixedIn-2.5` once the change is submitted, but before the
 release.
 
 After the release is actually made, you can search in Google Code for
-``Status=Submitted FixedIn=2.5'' and then batch update these changes
+`Status=Submitted FixedIn=2.5` and then batch update these changes
-to say `Status=Released`. Make sure the pulldown says ``All Issues''
+to say `Status=Released`. Make sure the pulldown says `All Issues`
 because `Status=Submitted` is considered a closed issue.
 
 

Documentation/install.txt

@@ -137,11 +137,11 @@ if existing Git repositories were not imported during 'init'.
 To control the Gerrit Code Review daemon that is running in the
 background, use the rc.d style start script created by 'init':
 
-====
+----
   review_site/bin/gerrit.sh start
   review_site/bin/gerrit.sh stop
   review_site/bin/gerrit.sh restart
-====
+----
 
 ('Optional') Configure the daemon to automatically start and stop
 with the operating system.
@@ -149,18 +149,18 @@ with the operating system.
 Uncomment the following 3 lines in the `'$site_path/bin/gerrit.sh'`
 script:
 
-====
+----
  chkconfig: 3 99 99
  description: Gerrit Code Review
  processname: gerrit
-====
+----
 
 Then link the `gerrit.sh` script into `rc3.d`:
 
-====
+----
   sudo ln -snf `pwd`/review_site/bin/gerrit.sh /etc/init.d/gerrit
   sudo ln -snf /etc/init.d/gerrit /etc/rc3.d/S90gerrit
-====
+----
 
 ('Optional') To enable autocompletion of the gerrit.sh commands, install
 autocompletion from the `/contrib/bash_completion` script.  Refer to the

Documentation/intro-project-owner.txt

@@ -69,11 +69,11 @@ Web UI. Otherwise you may inspect the history locally. If you have
 cloned the repository you can do this by executing the following
 commands:
 
-====
+----
   $ git fetch origin refs/meta/config:config
   $ git checkout config
   $ git log project.config
-====
+----
 
 Non project owners may still edit the access rights and propose the
 modifications to the project owners by clicking on the `Save for
@@ -519,11 +519,11 @@ Often comment links are used to link an ID in a commit message footer
 to an issue in an issue tracker system. For example, to link the ID
 from the `Bug` footer to Jira the following configuration can be used:
 
-====
+----
   [commentlink "myjira"]
     match = ([Bb][Uu][Gg]:\\s+)(\\S+)
     link =  https://myjira/browse/$2
-====
+----
 
 [[reviewers]]
 == Reviewers
@@ -594,11 +594,11 @@ build, execute the tests or even do a deployment.
 The project-specific download commands must be configured in the
 `project.config` file in the `refs/meta/config` branch of the project:
 +
-====
+----
   [plugin "project-download-commands"]
     Build = git fetch ${url} ${ref} && git checkout FETCH_HEAD && buck build ${project}
     Update = git fetch ${url} ${ref} && git checkout FETCH_HEAD && git submodule update
-====
+----
 +
 Project-specific download commands that are defined on a parent project
 are inherited by the child projects. A child project can overwrite an
@@ -705,9 +705,9 @@ git filter-branch] command to rewrite the committer information for all
 commits (the author information that records who was writing the code
 stays intact; signed tags will lose their signature):
 
-====
+----
   $ git filter-branch --tag-name-filter cat --env-filter 'GIT_COMMITTER_NAME="John Doe"; GIT_COMMITTER_EMAIL="john.doe@example.com";' -- --all
-====
+----
 
 If a link:config-gerrit.html#receive.maxObjectSizeLimit[max object size
 limit] is configured on the server you may need to remove large objects
@@ -715,20 +715,22 @@ from the history before you are able to push. To find large objects in
 the history of your project you can use the `reposize.sh` script which
 you can download from Gerrit:
 
+----
   $ curl -Lo reposize.sh http://review.example.com:8080/tools/scripts/reposize.sh
 
 or
 
   $ scp -p -P 29418 john.doe@review.example.com:scripts/reposize.sh .
+----
 
 You can then use the
 link:https://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html[
 git filter-branch] command to remove the large objects from the history
 of all branches:
 
-====
+----
   $ git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch path/to/large-file.jar' -- --all
-====
+----
 
 Since this command rewrites all commits in the repository it's a good
 idea to create a fresh clone from this rewritten repository before

Documentation/pgm-LocalUsernamesToLowerCase.txt

@@ -48,9 +48,9 @@ connectivity to the metadata database.
 == EXAMPLES
 To convert the local username of every account to lower case:
 
-====
+----
 	$ java -jar gerrit.war LocalUsernamesToLowerCase -d site_path
-====
+----
 
 == SEE ALSO
 

Documentation/pgm-gsql.txt

@@ -32,7 +32,7 @@ managed Git repositories.
 == EXAMPLES
 To manually correct a user's SSH user name:
 
-====
+----
 	$ java -jar gerrit.war gsql
 	Welcome to Gerrit Code Review v2.0.25
 	(PostgreSQL 8.3.8)
@@ -43,7 +43,7 @@ To manually correct a user's SSH user name:
 	UPDATE 1; 1 ms
 	gerrit> \q
 	Bye
-====
+----
 
 GERRIT
 ------

Documentation/pgm-prolog-shell.txt

@@ -22,7 +22,7 @@ and testing.
 == EXAMPLES
 Define a simple predicate and test it:
 
-====
+----
 	$ cat >simple.pl
 	food(apple).
 	food(orange).
@@ -45,7 +45,7 @@ Define a simple predicate and test it:
 
 	no
 	| ?-
-====
+----
 
 GERRIT
 ------

Documentation/pgm-rulec.txt

@@ -39,9 +39,9 @@ link:config-gerrit.html#cache.directory[cache.directory].
 == EXAMPLES
 To compile a rule JAR file for test/project:
 
-====
+----
 	$ java -jar gerrit.war rulec -d site_path test/project
-====
+----
 
 GERRIT
 ------

Documentation/project-configuration.txt

@@ -22,9 +22,9 @@ manually].
 
 . Create a Git repository under `gerrit.basePath`:
 +
-====
+----
   git --git-dir=$base_path/new/project.git init
-====
+----
 +
 [TIP]
 By tradition the repository directory name should have a `.git`
@@ -33,17 +33,17 @@ suffix.
 To also make this repository available over the anonymous git://
 protocol, don't forget to create a `git-daemon-export-ok` file:
 +
-====
+----
   touch $base_path/new/project.git/git-daemon-export-ok
-====
+----
 
 . Register Project
 +
 Either restart the server, or flush the `project_list` cache:
 +
-====
+----
   ssh -p 29418 localhost gerrit flush-caches --cache project_list
-====
+----
 
 [[project_options]]
 == Project Options
@@ -262,9 +262,9 @@ There are several ways to delete a branch:
   REST endpoint
 - by using a git client to force push nothing to an existing branch
 +
-====
+----
   $ git push --force origin :refs/heads/<branch-to-delete>
-====
+----
 
 To be able to delete branches, the user must have the
 link:access-control.html#category_push[Push] access right with the

Documentation/prolog-cookbook.txt

@@ -92,14 +92,14 @@ Project specific submit rules are stored in the `rules.pl` file in the
 checkout the `refs/meta/config` branch in order to create or edit the `rules.pl`
 file:
 
-====
+----
   $ git fetch origin refs/meta/config:config
   $ git checkout config
   ... edit or create the rules.pl file
   $ git add rules.pl
   $ git commit -m "My submit rules"
   $ git push origin HEAD:refs/meta/config
-====
+----
 
 [[HowToWriteSubmitRules]]
 == How to write submit rules
@@ -113,14 +113,14 @@ Conceptually we can imagine that Gerrit adds a set of facts about the change
 `C` on top of the `rules.pl` file and then consults it. The set of facts about
 the change `C` will look like:
 
-====
+----
   :- package gerrit.                                                   <1>
 
   commit_author(user(1000000), 'John Doe', 'john.doe@example.com').    <2>
   commit_committer(user(1000000), 'John Doe', 'john.doe@example.com'). <3>
   commit_message('Add plugin support to Gerrit').                      <4>
   ...
-====
+----
 
 <1> Gerrit will provide its facts in a package named `gerrit`. This means we
 have to use qualified names when writing our code and referencing these facts.
@@ -139,9 +139,9 @@ needed criteria for the change to become submittable. This means that Gerrit has
 an expectation on the format and value of the result of the `submit_rule`
 predicate which is expected to be a `submit` term of the following format:
 
-====
+----
   submit(label(label-name, status) [, label(label-name, status)]*)
-====
+----
 
 where `label-name` is usually `'Code-Review'` or `'Verified'` but could also
 be any other string (see examples below). The `status` is one of:
@@ -173,11 +173,11 @@ needed for the change to become submittable.
 
 Here some examples of possible return values from the `submit_rule` predicate:
 
-====
+----
   submit(label('Code-Review', ok(_)))                               <1>
   submit(label('Code-Review', ok(_)), label('Verified', reject(_))) <2>
   submit(label('Author-is-John-Doe', need(_))                       <3>
-====
+----
 
 <1> label `'Code-Review'` is met. As there are no other labels in the
     return result, the change is submittable.
@@ -217,10 +217,9 @@ The purpose of the submit filter is, as its name says, to filter the results
 of the `submit_rule`. Therefore, the `submit_filter` predicate has two
 parameters:
 
-====
+----
   submit_filter(In, Out) :- ...
-====
+----
-
 Gerrit will invoke `submit_filter` with the `In` parameter containing a `submit`
 structure produced by the `submit_rule` and will take the value of the `Out`
 parameter as the result.
@@ -240,7 +239,7 @@ can avoid implementing the same `submit_rule` in all their projects.
 
 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>
   |
@@ -255,7 +254,7 @@ of the results of the `submit_rule` and `submit_filter` predicates.
   |
   MyProject
       submit_rule(X) :- ...       <1>
-====
+----
 
 <1> The `submit_rule` of `MyProject` is invoked first.
 <2> The result `X` is filtered through the `submit_filter` from the `Parent-1`
@@ -289,9 +288,9 @@ represents one of the supported submit types:
 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
@@ -306,9 +305,9 @@ command link:cmd-test-submit-rule.html[test-submit rule] loads a specific change
 and executes the `submit_rule`. It optionally reads the rule from from `stdin`
 to facilitate easy testing.
 
-====
+----
   $ cat rules.pl | ssh gerrit_srv gerrit test-submit rule I45e080b105a50a625cc8e1fb5b357c0bfabe6d68 -s
-====
+----
 
 == Prolog vs Gerrit plugin for project specific submit rules
 Since version 2.5 Gerrit supports plugins and extension points. A plugin or an

Documentation/user-notify.txt

@@ -45,24 +45,24 @@ branch. Consult link:access-control.html[access controls] for
 details on how access permissions work.
 
 Initialize a temporary Git repository to edit the configuration:
-====
+----
   mkdir cfg_dir
   cd cfg_dir
   git init
-====
+----
 
 Download the existing configuration from Gerrit:
-====
+----
   git fetch ssh://localhost:29418/project refs/meta/config
   git checkout FETCH_HEAD
-====
+----
 
 Enable notifications to an email address by adding to
 `project.config`, this can be done using the `git config` command:
-====
+----
   git config -f project.config --add notify.team.email team-address@example.com
   git config -f project.config --add notify.team.email paranoid-manager@example.com
-====
+----
 
 Examining the project.config file with any text editor should show
 a new notify section describing the email addresses to deliver to:
@@ -79,10 +79,10 @@ group it delivers to is typical. Multiple sections can be specified
 if different filters are needed.
 
 Commit the configuration change, and push it back:
-====
+----
   git commit -a -m "Notify team-address@example.com of changes"
   git push ssh://localhost:29418/project HEAD:refs/meta/config
-====
+----
 
 [[notify.name.email]]notify.<name>.email::
 +
@@ -132,11 +132,11 @@ has set the filtering options correctly. Project owners can implement
 security filtering by adding the `visibleto:groupname` predicate to
 the filter expression, for example:
 
-====
+----
   [notify "Developers"]
   	email = team-address@example.com
   	filter = visibleto:Developers
-====
+----
 
 When sending email to an internal group, the internal group's read
 access is automatically checked by Gerrit and therefore does not

Documentation/user-submodules.txt

@@ -46,9 +46,9 @@ Also consider 'sub' available in a running Gerrit instance on "server".
 With this feature, one could attach 'sub' inside of 'super' repository
 at path 'sub' by executing the following command when being inside
 'super':
-====
+----
 git submodule add ssh://server/sub sub
-====
+----
 
 Still considering the above example, after its execution notice that
 inside the local repository 'super' the 'sub' folder is considered a
@@ -56,9 +56,9 @@ gitlink to the external repository 'sub'. Also notice a file called
 .gitmodules is created (it is a configuration file containing the
 subscription of 'sub'). To provide the SHA-1 each gitlink points to in
 the external repository, one should use the command:
-====
+----
 git submodule status
-====
+----
 
 In the example provided, if 'sub' is updated and 'super' is supposed
 to see the latest SHA-1 (considering here 'sub' has only the master
@@ -78,34 +78,34 @@ related information is allowed to be exposed in the superproject,
 the submodule needs to be configured to enable the superproject subscription.
 In a submodule client, checkout the refs/meta/config branch and edit
 the subscribe capabilities in the 'project.config' file:
-====
+----
     git fetch <remote> refs/meta/config:refs/meta/config
     git checkout refs/meta/config
     $EDITOR project.config
-====
+----
 and add the following lines:
-====
+----
   [allowSuperproject "<superproject>"]
     refs = <refspec>
-====
+----
 where the 'superproject' should be the exact project name of the superproject.
 The refspec defines which branches of the submodule are allowed to be
 subscribed to which branches of the superproject. See below for
 link:#acl_refspec[details]. Push the configuration for review and
 submit the change:
-====
+----
   git add project.config
   git commit -m "Allow <superproject> to subscribe"
   git push <remote> HEAD:refs/for/refs/meta/config
-====
+----
 After the change is integrated a superproject subscription is possible.
 
 The configuration is inherited from parent projects, such that you can have
 a configuration in the "All-Projects" project like:
-====
+----
     [allowSuperproject "my-only-superproject"]
         refs = refs/heads/*:refs/heads/*
-====
+----
 and then you don't have to worry about configuring the individual projects
 any more. Child projects cannot negate the parent's configuration.
 
@@ -152,25 +152,25 @@ to Git style RefSpecs used for pushing in Git. Regular expressions
 as found in the ACL configuration are not supported. The most restrictive
 RefSpec is allowing one specific branch of the submodule to be subscribed
 to one specific branch of the superproject via:
-====
+----
   [allowSuperproject "<superproject>"]
     refs = refs/heads/<submodule-branch>:refs/heads/<superproject-branch>
-====
+----
 
 If you want to allow for a 1:1 mapping, i.e. 'master' maps to 'master',
 'stable' maps to 'stable', but not allowing 'master' to be subscribed to
 'stable':
-====
+----
   [allowSuperproject "<superproject>"]
     refs = refs/heads/*:refs/heads/*
-====
+----
 
 If you want to enable a branch to be subscribed to any other branch of
 the superproject, omit the second part of the RefSpec:
-====
+----
   [allowSuperproject "<superproject>"]
     refs = refs/heads/<submodule-branch>
-====
+----
 
 === Subscription Limitations
 

Documentation/user-upload.txt

@@ -54,16 +54,16 @@ Typically SSH keys are stored in your home directory, under `~/.ssh`.
 If you don't have any keys yet, you can create a new one and protect
 it with a passphrase:
 
-====
+----
   ssh-keygen -t rsa
-====
+----
 
 Then copy the content of the public key file onto your clipboard,
 and paste it into Gerrit's web interface:
 
-====
+----
   cat ~/.ssh/id_rsa.pub
-====
+----
 
 [TIP]
 Users who frequently upload changes will also want to consider
@@ -80,8 +80,7 @@ To verify your SSH key is working correctly, try using an SSH client
 to connect to Gerrit's SSHD port.  By default Gerrit runs on
 port 29418, using the same hostname as the web server:
 
-====
+----
-..................................................................
   $ ssh -p 29418 sshusername@hostname
 
     ****    Welcome to Gerrit Code Review    ****
@@ -94,8 +93,7 @@ port 29418, using the same hostname as the web server:
     git clone ssh://sshusername@hostname:29418/REPOSITORY_NAME.git
 
   Connection to hostname closed.
-..................................................................
+----
-====
 
 In the command above, `sshusername` was configured as `Username` on
 the `Profile` tab of the `Settings` screen.  If it is not set,
@@ -105,10 +103,10 @@ To determine the port number Gerrit is running on, visit the special
 information URL `http://'hostname'/ssh_info`, and copy the port
 number from the second field:
 
-====
+----
   $ curl http://hostname/ssh_info
   hostname 29418
-====
+----
 
 If you are developing an automated tool to perform uploads to Gerrit,
 let the user supply the hostname or the web address for Gerrit,
@@ -125,17 +123,17 @@ or `NOT_AVAILABLE` if the SSHD server is not currently running.
 To create new changes for review, simply push to the project's
 magical `refs/for/'branch'` ref using any Git client tool:
 
-====
+----
   git push ssh://sshusername@hostname:29418/projectname HEAD:refs/for/branch
-====
+----
 
 E.g. `john.doe` can use git push to upload new changes for the
 `experimental` branch of project `kernel/common`, hosted at the
 `git.example.com` Gerrit server:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental
-====
+----
 
 Each new commit uploaded by the `git push` client will be
 converted into a change record on the server.  The remote ref
@@ -163,9 +161,9 @@ the `notify` option:
 
 By default all email notifications are sent.
 
-====
+----
   git push ssh://bot@git.example.com:29418/kernel/common HEAD:refs/for/master%notify=NONE
-====
+----
 
 [[topic]]
 To include a short tag associated with all of the changes in the
@@ -174,17 +172,17 @@ the destination branch name. In this example the short topic tag
 'driver/i42' will be saved on each change this push creates or
 updates:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%topic=driver/i42
-====
+----
 
 [[message]]
 A comment message can be applied to the change by using the `message` (or `m`)
 option:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%m=This_is_a_rebase_on_master
-====
+----
 
 .Note
 ****
@@ -196,16 +194,16 @@ it will then be applied as "This is a rebase on master".
 Review labels can be applied to the change by using the `label` (or `l`)
 option in the reference:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%l=Verified+1
-====
+----
 
 The `l='label[score]'` option may be specified more than once to
 apply multiple review labels.
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental%l=Code-Review+1,l=Verified+1
-====
+----
 
 The value is optional.  If not specified, it defaults to +1 (if
 the label range allows it).
@@ -214,9 +212,9 @@ the label range allows it).
 A change edit can be pushed by specifying the `edit` (or `e`) option on
 the reference:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%edit
-====
+----
 
 There is at most one change edit per user and change. In order to push
 a change edit the change must already exist.
@@ -232,7 +230,7 @@ consider adding an SSH host block in `~/.ssh/config` to remember
 your username, hostname and port number.  This permits the use of
 shorter URLs on the command line, such as:
 
-====
+----
   $ cat ~/.ssh/config
   ...
   Host tr
@@ -241,15 +239,15 @@ shorter URLs on the command line, such as:
     User john.doe
 
   $ git push tr:kernel/common HEAD:refs/for/experimental
-====
+----
 
 Specific reviewers can be requested and/or additional 'carbon
 copies' of the notification message may be sent by including the
 `reviewer` (or `r`) and `cc` options in the reference:
 
-====
+----
   git push tr:kernel/common HEAD:refs/for/experimental%r=a@a.com,cc=b@o.com
-====
+----
 
 The `r='email'` and `cc='email'` options may be specified as many
 times as necessary to cover all interested parties. Gerrit will
@@ -261,7 +259,7 @@ If you are frequently sending changes to the same parties and/or
 branches, consider adding a custom remote block to your project's
 `.git/config` file:
 
-====
+----
   $ cat .git/config
   ...
   [remote "exp"]
@@ -269,7 +267,7 @@ branches, consider adding a custom remote block to your project's
     push = HEAD:refs/for/experimental%r=a@a.com,cc=b@o.com
 
   $ git push exp
-====
+----
 
 
 [[push_replace]]
@@ -310,9 +308,9 @@ commit to the change's ref.  For example, to add the commit whose
 SHA-1 starts with `c0ffee` as a new patch set for change number
 `1979`, use the push refspec `c0ffee:refs/changes/1979` as below:
 
-====
+----
   git push ssh://sshusername@hostname:29418/projectname c0ffee:refs/changes/1979
-====
+----
 
 This form can be combined together with `refs/for/'branchname'`
 (above) to simultaneously create new changes and replace changes
@@ -320,7 +318,7 @@ during one network transaction.
 
 For example, consider the following sequence of events:
 
-====
+----
   $ git commit -m A                    ; # create 3 commits
   $ git commit -m B
   $ git commit -m C
@@ -337,7 +335,7 @@ For example, consider the following sequence of events:
       HEAD~3:refs/changes/1500
       HEAD~1:refs/changes/1501
       HEAD~0:refs/changes/1502         ; # upload replacements
-====
+----
 
 At the final step during the push Gerrit will attach A' as a new
 patch set on change 1500; B' as a new patch set on change 1501; C'
@@ -404,9 +402,9 @@ for teams that don't want to do code review but want to use Gerrit's
 submit strategies to handle contention on busy branches.  Using
 `%submit` creates a change and submits it immediately:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%submit
-====
+----
 
 On auto-merge of a change neither labels nor submit rules are checked.
 If the merge fails the change stays open, but when pushing a new patch
@@ -426,18 +424,18 @@ that have never before been seen by the Gerrit server. Clients
 may override that behavior and force new changes to be created
 by setting the merge base SHA-1 using the '%base' argument:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%base=$(git rev-parse origin/master)
-====
+----
 
 It is also possible to specify more than one '%base' argument.
 This may be useful when pushing a merge commit. Note that the '%'
 character has only to be provided once, for the first '%base'
 argument:
 
-====
+----
   git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%base=commit-id1,base=commit-id2
-====
+----
 
 
 == repo upload