Fix unordered list spacing

Correct the spacing of unordered markdown lists
in docs, to maintain standards of documentation,
in /user and others.

doc/administration/gitaly/index.md

@@ -359,7 +359,7 @@ To configure Gitaly with TLS:
    gitaly['tls_listen_addr'] = "0.0.0.0:9999"
    gitaly['certificate_path'] = "path/to/cert.pem"
    gitaly['key_path'] = "path/to/key.pem"
-  ```
+   ```
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).

doc/ci/introduction/index.md

@@ -146,14 +146,14 @@ so, GitLab CI/CD:
 - Runs automated scripts (sequential or parallel) to:
   - Build and test your app.
   - Preview the changes per merge request with Review Apps, as you
-  would see in your `localhost`.
+    would see in your `localhost`.
 Once you're happy with your implementation:
 - Get your code reviewed and approved.
 - Merge the feature branch into the default branch.
   - GitLab CI/CD deploys your changes automatically to a production environment.
--  And finally, you and your team can easily roll it back if something goes wrong.
+- And finally, you and your team can easily roll it back if something goes wrong.
 ![GitLab workflow example](img/gitlab_workflow_example_11_9.png)
@@ -176,24 +176,24 @@ you'll see some of the features available in GitLab
 according to each stage (Verify, Package, Release).
 1. **Verify**:
-    - Automatically build and test your application with Continuous Integration.
-    - Analyze your source code quality with [GitLab Code Quality](../../user/project/merge_requests/code_quality.md). **(STARTER)**
-    - Determine the performance impact of code changes with [Browser Performance Testing](../../user/project/merge_requests/browser_performance_testing.md). **(PREMIUM)**
-    - Perform a series of tests, such as [Container Scanning](../../user/application_security/container_scanning/index.md) **(ULTIMATE)**, [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) **(ULTIMATE)**, and [JUnit tests](../junit_test_reports.md).
-    - Deploy your changes with [Review Apps](../review_apps/index.md) to preview the app changes on every branch.
+   - Automatically build and test your application with Continuous Integration.
+   - Analyze your source code quality with [GitLab Code Quality](../../user/project/merge_requests/code_quality.md). **(STARTER)**
+   - Determine the performance impact of code changes with [Browser Performance Testing](../../user/project/merge_requests/browser_performance_testing.md). **(PREMIUM)**
+   - Perform a series of tests, such as [Container Scanning](../../user/application_security/container_scanning/index.md) **(ULTIMATE)**, [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) **(ULTIMATE)**, and [JUnit tests](../junit_test_reports.md).
+   - Deploy your changes with [Review Apps](../review_apps/index.md) to preview the app changes on every branch.
 1. **Package**:
-    - Store Docker images with [Container Registry](../../user/project/container_registry.md).
-    - Store NPM packages with [NPM Registry](../../user/project/packages/npm_registry.md). **(PREMIUM)**
-    - Store Maven artifacts with [Maven Repository](../../user/project/packages/maven_repository.md). **(PREMIUM)**
+   - Store Docker images with [Container Registry](../../user/project/container_registry.md).
+   - Store NPM packages with [NPM Registry](../../user/project/packages/npm_registry.md). **(PREMIUM)**
+   - Store Maven artifacts with [Maven Repository](../../user/project/packages/maven_repository.md). **(PREMIUM)**
 1. **Release**:
-    - Continuous Deployment, automatically deploying your app to production.
-    - Continuous Delivery, manually click to deploy your app to production.
-    - Deploy static websites with [GitLab Pages](../../user/project/pages/index.md).
-    - Ship features to only a portion of your pods and let a percentage of your user base to visit the temporarily deployed feature with [Canary Deployments](../../user/project/canary_deployments.md). **(PREMIUM)**
-    - Deploy your features behind [Feature Flags](../../user/project/operations/feature_flags.md). **(PREMIUM)**
-    - Add release notes to any Git tag with [GitLab Releases](../../user/project/releases/index.md).
-    - View of the current health and status of each CI environment running on Kubernetes with [Deploy Boards](../../user/project/deploy_boards.md). **(PREMIUM)**
-    -  Deploy your application to a production environment in a Kubernetes cluster with [Auto Deploy](../../topics/autodevops/index.md#auto-deploy).
+   - Continuous Deployment, automatically deploying your app to production.
+   - Continuous Delivery, manually click to deploy your app to production.
+   - Deploy static websites with [GitLab Pages](../../user/project/pages/index.md).
+   - Ship features to only a portion of your pods and let a percentage of your user base to visit the temporarily deployed feature with [Canary Deployments](../../user/project/canary_deployments.md). **(PREMIUM)**
+   - Deploy your features behind [Feature Flags](../../user/project/operations/feature_flags.md). **(PREMIUM)**
+   - Add release notes to any Git tag with [GitLab Releases](../../user/project/releases/index.md).
+   - View of the current health and status of each CI environment running on Kubernetes with [Deploy Boards](../../user/project/deploy_boards.md). **(PREMIUM)**
+   - Deploy your application to a production environment in a Kubernetes cluster with [Auto Deploy](../../topics/autodevops/index.md#auto-deploy).
 With GitLab CI/CD you can also:

doc/user/clusters/applications.md

@@ -19,8 +19,8 @@ This namespace:
 To see a list of available applications to install:
 1. For a:
-    - Project-level cluster, navigate to your project's **Operations > Kubernetes**.
-    - Group-level cluster, navigate to your group's **Kubernetes** page.
+   - Project-level cluster, navigate to your project's **Operations > Kubernetes**.
+   - Group-level cluster, navigate to your group's **Kubernetes** page.
 Install Helm first as it's used to install other applications.
@@ -232,8 +232,8 @@ The applications below can be upgraded.
 To upgrade an application:
 1. For a:
-    - Project-level cluster, navigate to your project's **Operations > Kubernetes**.
-    - Group-level cluster, navigate to your group's **Kubernetes** page.
+   - Project-level cluster, navigate to your project's **Operations > Kubernetes**.
+   - Group-level cluster, navigate to your group's **Kubernetes** page.
 1. Select your cluster.
 1. If an upgrade is available, the **Upgrade** button is displayed. Click the button to upgrade.
@@ -259,8 +259,8 @@ The applications below can be uninstalled.
 To uninstall an application:
 1. For a:
-    - Project-level cluster, navigate to your project's **Operations > Kubernetes**.
-    - Group-level cluster, navigate to your group's **Kubernetes** page.
+   - Project-level cluster, navigate to your project's **Operations > Kubernetes**.
+   - Group-level cluster, navigate to your group's **Kubernetes** page.
 1. Select your cluster.
 1. Click the **Uninstall** button for the application.

doc/user/group/subgroups/index.md

@@ -28,39 +28,39 @@ only 1 parent group. It resembles a directory behavior or a nested items list:
 - Group 1
   - Group 1.1
   - Group 1.2
-      - Group 1.2.1
-      - Group 1.2.2
-          - Group 1.2.2.1
+    - Group 1.2.1
+    - Group 1.2.2
+      - Group 1.2.2.1
 In a real world example, imagine maintaining a GNU/Linux distribution with the
 first group being the name of the distribution, and subsequent groups split as follows:
 - Organization Group - GNU/Linux distro
   - Category Subgroup - Packages
-      - (project) Package01
-      - (project) Package02
+    - (project) Package01
+    - (project) Package02
   - Category Subgroup - Software
-      - (project) Core
-      - (project) CLI
-      - (project) Android app
-      - (project) iOS app
+    - (project) Core
+    - (project) CLI
+    - (project) Android app
+    - (project) iOS app
   - Category Subgroup - Infra tools
-      - (project) Ansible playbooks
+    - (project) Ansible playbooks
 Another example of GitLab as a company would be the following:
 - Organization Group - GitLab
   - Category Subgroup - Marketing
-      - (project) Design
-      - (project) General
+    - (project) Design
+    - (project) General
   - Category Subgroup - Software
-      - (project) GitLab CE
-      - (project) GitLab EE
-      - (project) Omnibus GitLab
-      - (project) GitLab Runner
-      - (project) GitLab Pages daemon
+    - (project) GitLab CE
+    - (project) GitLab EE
+    - (project) Omnibus GitLab
+    - (project) GitLab Runner
+    - (project) GitLab Pages daemon
   - Category Subgroup - Infra tools
-      - (project) Chef cookbooks
+    - (project) Chef cookbooks
   - Category Subgroup - Executive team
 ---
@@ -88,13 +88,13 @@ To create a subgroup:
 1. In the group's dashboard expand the **New project** split button, select
    **New subgroup** and click the **New subgroup** button.
-    ![Subgroups page](img/create_subgroup_button.png)
+   ![Subgroups page](img/create_subgroup_button.png)
 1. Create a new group like you would normally do. Notice that the parent group
    namespace is fixed under **Group path**. The visibility level can differ from
    the parent group.
-    ![Subgroups page](img/create_new_group.png)
+   ![Subgroups page](img/create_new_group.png)
 1. Click the **Create group** button and you will be taken to the new group's
    dashboard page.

doc/user/project/badges.md

@@ -17,10 +17,10 @@ If you find that you have to add the same badges to several projects, you may wa
 To add a new badge to a project:
-1.  Navigate to your project's **Settings > General > Badges**.
-1.  Under "Link", enter the URL that the badges should point to and under
-    "Badge image URL" the URL of the image that should be displayed.
-1.  Submit the badge by clicking the **Add badge** button.
+1. Navigate to your project's **Settings > General > Badges**.
+1. Under "Link", enter the URL that the badges should point to and under
+   "Badge image URL" the URL of the image that should be displayed.
+1. Submit the badge by clicking the **Add badge** button.
 After adding a badge to a project, you can see it in the list below the form.
 You can edit it by clicking on the pen icon next to it or to delete it by
@@ -39,10 +39,10 @@ project, consider adding them on the [project level](#project-badges) or use
 To add a new badge to a group:
-1.  Navigate to your group's **Settings > General > Badges**.
-1.  Under "Link", enter the URL that the badges should point to and under
-    "Badge image URL" the URL of the image that should be displayed.
-1.  Submit the badge by clicking the **Add badge** button.
+1. Navigate to your group's **Settings > General > Badges**.
+1. Under "Link", enter the URL that the badges should point to and under
+   "Badge image URL" the URL of the image that should be displayed.
+1. Submit the badge by clicking the **Add badge** button.
 After adding a badge to a group, you can see it in the list below the form.
 You can edit the badge by clicking on the pen icon next to it or to delete it

doc/user/project/cycle_analytics.md

@@ -21,19 +21,19 @@ Analytics** tab.
 There are seven stages that are tracked as part of the Cycle Analytics calculations.
 - **Issue** (Tracker)
-    - Time to schedule an issue (by milestone or by adding it to an issue board)
+  - Time to schedule an issue (by milestone or by adding it to an issue board)
 - **Plan** (Board)
-    - Time to first commit
+  - Time to first commit
 - **Code** (IDE)
-    - Time to create a merge request
+  - Time to create a merge request
 - **Test** (CI)
-    - Time it takes GitLab CI/CD to test your code
+  - Time it takes GitLab CI/CD to test your code
 - **Review** (Merge Request/MR)
-    - Time spent on code review
+  - Time spent on code review
 - **Staging** (Continuous Deployment)
-    - Time between merging and deploying to production
+  - Time between merging and deploying to production
 - **Production** (Total)
-    - Total lifecycle time; i.e. the velocity of the project or team
+  - Total lifecycle time; i.e. the velocity of the project or team
 ## How the data is measured

doc/user/project/import/svn.md

@@ -9,13 +9,13 @@ between the two, for more information consult your favorite search engine.
 There are two approaches to SVN to Git migration:
 1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
-    - Makes the GitLab repository to mirror the SVN project.
-    - Git and SVN repositories are kept in sync; you can use either one.
-    - Smoothens the migration process and allows to manage migration risks.
+   - Makes the GitLab repository to mirror the SVN project.
+   - Git and SVN repositories are kept in sync; you can use either one.
+   - Smoothens the migration process and allows to manage migration risks.
 1. [Cut over migration](#cut-over-migration-with-svn2git) which:
-     - Translates and imports the existing data and history from SVN to Git.
-     - Is a fire and forget approach, good for smaller teams.
+   - Translates and imports the existing data and history from SVN to Git.
+   - Is a fire and forget approach, good for smaller teams.
 ## Smooth migration with a Git/SVN mirror using SubGit

doc/user/project/index.md

@@ -66,15 +66,15 @@ When you create a project in GitLab, you'll have access to a large number of
   to automatically set up your app's deployment
   - [Enable and disable GitLab CI](../../ci/enable_or_disable_ci.md)
   - [Pipelines](../../ci/pipelines.md): Configure and visualize
-  your GitLab CI/CD pipelines from the UI
-     - [Scheduled Pipelines](pipelines/schedules.md): Schedule a pipeline
-     to start at a chosen time
-     - [Pipeline Graphs](../../ci/pipelines.md#visualizing-pipelines): View your
-     entire pipeline from the UI
-     - [Job artifacts](pipelines/job_artifacts.md): Define,
-     browse, and download job artifacts
-     - [Pipeline settings](pipelines/settings.md): Set up Git strategy (choose the default way your repository is fetched from GitLab in a job),
-     timeout (defines the maximum amount of time in minutes that a job is able run), custom path for `.gitlab-ci.yml`, test coverage parsing, pipeline's visibility, and much more
+    your GitLab CI/CD pipelines from the UI
+    - [Scheduled Pipelines](pipelines/schedules.md): Schedule a pipeline
+      to start at a chosen time
+    - [Pipeline Graphs](../../ci/pipelines.md#visualizing-pipelines): View your
+      entire pipeline from the UI
+    - [Job artifacts](pipelines/job_artifacts.md): Define,
+      browse, and download job artifacts
+    - [Pipeline settings](pipelines/settings.md): Set up Git strategy (choose the default way your repository is fetched from GitLab in a job),
+      timeout (defines the maximum amount of time in minutes that a job is able run), custom path for `.gitlab-ci.yml`, test coverage parsing, pipeline's visibility, and much more
   - [Kubernetes cluster integration](clusters/index.md): Connecting your GitLab project
     with a Kubernetes cluster
   - [Feature Flags](operations/feature_flags.md): Feature flags allow you to ship a project in

doc/user/project/integrations/mock_ci.md

@@ -5,9 +5,9 @@
 To set up the mock CI service server, respond to the following endpoints
 - `commit_status`: `#{project.namespace.path}/#{project.path}/status/#{sha}.json`
-   - Have your service return `200 { status: ['failed'|'canceled'|'running'|'pending'|'success'|'success-with-warnings'|'skipped'|'not_found'] }`
+  - Have your service return `200 { status: ['failed'|'canceled'|'running'|'pending'|'success'|'success-with-warnings'|'skipped'|'not_found'] }`
    - If the service returns a 404, it is interpreted as `pending`
 - `build_page`: `#{project.namespace.path}/#{project.path}/status/#{sha}`
-   - Just where the build is linked to, doesn't matter if implemented
+  - Just where the build is linked to, doesn't matter if implemented
 For an example of a mock CI server, see [`gitlab-org/gitlab-mock-ci-service`](https://gitlab.com/gitlab-org/gitlab-mock-ci-service)

doc/user/project/integrations/webhooks.md

@@ -58,13 +58,13 @@ Navigate to the webhooks page by going to your project's
 If you are writing your own endpoint (web server) that will receive
 GitLab webhooks keep in mind the following things:
--   Your endpoint should send its HTTP response as fast as possible. If
-    you wait too long, GitLab may decide the hook failed and retry it.
--   Your endpoint should ALWAYS return a valid HTTP response. If you do
-    not do this then GitLab will think the hook failed and retry it.
-    Most HTTP libraries take care of this for you automatically but if
-    you are writing a low-level hook this is important to remember.
--   GitLab ignores the HTTP status code returned by your endpoint.
+- Your endpoint should send its HTTP response as fast as possible. If
+  you wait too long, GitLab may decide the hook failed and retry it.
+- Your endpoint should ALWAYS return a valid HTTP response. If you do
+  not do this then GitLab will think the hook failed and retry it.
+  Most HTTP libraries take care of this for you automatically but if
+  you are writing a low-level hook this is important to remember.
+- GitLab ignores the HTTP status code returned by your endpoint.
 ## Secret token

doc/user/project/issue_board.md

@@ -143,10 +143,10 @@ Create lists for each of your team members and quickly drag-and-drop issues onto
 - **Issue Board** - Each board represents a unique view for your issues. It can have multiple lists with each list consisting of issues represented by cards.
 - **List** - A column on the issue board that displays issues matching certain attributes. In addition to the default lists of 'Open' and 'Closed' issue, each additional list will show issues matching your chosen label or assignee. On the top of that list you can see the number of issues that belong to it.
-   - **Label list**: a list based on a label. It shows all opened issues with that label.
-   - **Assignee list**: a list which includes all issues assigned to a user.
-   - **Open** (default): shows all open issues that do not belong to one of the other lists. Always appears as the leftmost list.
-   - **Closed** (default): shows all closed issues. Always appears as the rightmost list.
+  - **Label list**: a list based on a label. It shows all opened issues with that label.
+  - **Assignee list**: a list which includes all issues assigned to a user.
+  - **Open** (default): shows all open issues that do not belong to one of the other lists. Always appears as the leftmost list.
+  - **Closed** (default): shows all closed issues. Always appears as the rightmost list.
 - **Card** - A box in the list that represents an individual issue. The information you can see on a card consists of the issue number, the issue title, the assignee, and the labels associated with the issue. You can drag cards from one list to another to change their label or assignee from that of the source list to that of the destination list.
 ## Permissions

doc/user/project/pages/introduction.md

@@ -83,23 +83,23 @@ You can enable Pages access control on your project, so that only
 1. Navigate to your project's **Settings > General > Permissions**.
 1. Toggle the **Pages** button to enable the access control.
-    NOTE: **Note:**
-    If you don't see the toggle button, that means that it's not enabled.
-    Ask your administrator to [enable it](../../../administration/pages/index.md#access-control).
+   NOTE: **Note:**
+   If you don't see the toggle button, that means that it's not enabled.
+   Ask your administrator to [enable it](../../../administration/pages/index.md#access-control).
 1. The Pages access control dropdown allows you to set who can view pages hosted
    with GitLab Pages, depending on your project's visibility:
-    - If your project is private:
-      - **Only project members**: Only project members will be able to browse the website.
-      - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
-    - If your project is internal:
-      - **Only project members**: Only project members will be able to browse the website.
-      - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership.
-      - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
-    - If your project is public:
-      - **Only project members**: Only project members will be able to browse the website.
-      - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+   - If your project is private:
+     - **Only project members**: Only project members will be able to browse the website.
+     - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+   - If your project is internal:
+     - **Only project members**: Only project members will be able to browse the website.
+     - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership.
+     - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+   - If your project is public:
+     - **Only project members**: Only project members will be able to browse the website.
+     - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
 1. Click **Save changes**.

doc/user/search/advanced_search_syntax.md

@@ -50,9 +50,9 @@ here's a quick guide:
 The Advanced Syntax Search also supports the use of filters. The available filters are:
- - filename: Filters by filename. You can use the glob (`*`) operator for fuzzy matching.
- - path: Filters by path. You can use the glob (`*`) operator for fuzzy matching.
- - extension: Filters by extension in the filename. Please write the extension without a leading dot. Exact match only.
+- filename: Filters by filename. You can use the glob (`*`) operator for fuzzy matching.
+- path: Filters by path. You can use the glob (`*`) operator for fuzzy matching.
+- extension: Filters by extension in the filename. Please write the extension without a leading dot. Exact match only.
 To use them, simply add them to your query in the format `<filter_name>:<value>` without
  any spaces between the colon (`:`) and the value.

doc/user/search/index.md

@@ -55,12 +55,12 @@ Selecting **Any** does the opposite. It returns results that have a non-empty va
 You can filter issues and merge requests by specific terms included in titles or descriptions.
 - Syntax
-    - Searches look for all the words in a query, in any order. E.g.: searching
-      issues for `display bug` will return all issues matching both those words, in any order.
-    - To find the exact term, use double quotes: `"display bug"`
+  - Searches look for all the words in a query, in any order. E.g.: searching
+    issues for `display bug` will return all issues matching both those words, in any order.
+  - To find the exact term, use double quotes: `"display bug"`
 - Limitation
-    - For performance reasons, terms shorter than 3 chars are ignored. E.g.: searching
-      issues for `included in titles` is same as `included titles`
+  - For performance reasons, terms shorter than 3 chars are ignored. E.g.: searching
+    issues for `included in titles` is same as `included titles`
 ![filter issues by specific terms](img/issue_search_by_term.png)

doc/workflow/forking_workflow.md

@@ -10,31 +10,25 @@ document more information about using branches to work together.
 Forking a project is in most cases a two-step process.
-1.  Click on the fork button located in the middle of the page or a project's
-    home page right next to the stars button.
-    ![Fork button](img/forking_workflow_fork_button.png)
-    ---
-1.  Once you do that, you'll be presented with a screen where you can choose
-    the namespace to fork to. Only namespaces (groups and your own
-    namespace) where you have write access to, will be shown. Click on the
-    namespace to create your fork there.
-    ![Choose namespace](img/forking_workflow_choose_namespace.png)
-    ---
-
-    **Note:**
-    If the namespace you chose to fork the project to has another project with
-    the same path name, you will be presented with a warning that the forking
-    could not be completed. Try to resolve the error and repeat the forking
-    process.
-
-    ![Path taken error](img/forking_workflow_path_taken_error.png)
-
-    ---
+1. Click on the fork button located in the middle of the page or a project's
+   home page right next to the stars button.
+   ![Fork button](img/forking_workflow_fork_button.png)
+1. Once you do that, you'll be presented with a screen where you can choose
+   the namespace to fork to. Only namespaces (groups and your own
+   namespace) where you have write access to, will be shown. Click on the
+   namespace to create your fork there.
+   ![Choose namespace](img/forking_workflow_choose_namespace.png)
+   **Note:**
+   If the namespace you chose to fork the project to has another project with
+   the same path name, you will be presented with a warning that the forking
+   could not be completed. Try to resolve the error and repeat the forking
+   process.
+   ![Path taken error](img/forking_workflow_path_taken_error.png)
 After the forking is done, you can start working on the newly created
 repository. There, you will have full [Owner](../user/permissions.md)

doc/workflow/repository_mirroring.md

@@ -92,9 +92,9 @@ The repository will push soon. To force a push, click the appropriate button.
 1. On the destination GitLab instance, create a [personal access token](../user/profile/personal_access_tokens.md) with `API` scope.
 1. On the source GitLab instance:
-    1. Fill in the **Git repository URL** field using this format: `https://oauth2@<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`.
-    1. Fill in **Password** field with the GitLab personal access token created on the destination GitLab instance.
-    1. Click the **Mirror repository** button.
+   1. Fill in the **Git repository URL** field using this format: `https://oauth2@<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`.
+   1. Fill in **Password** field with the GitLab personal access token created on the destination GitLab instance.
+   1. Click the **Mirror repository** button.
 ## Pulling from a remote repository **(STARTER)**
@@ -118,9 +118,9 @@ To configure mirror pulling for an existing project:
 1. Select **Pull** from the **Mirror direction** dropdown.
 1. Select an authentication method from the **Authentication method** dropdown, if necessary.
 1. If necessary, check the following boxes:
-    - **Overwrite diverged branches**.
-    - **Trigger pipelines for mirror updates**.
-    - **Only mirror protected branches**.
+   - **Overwrite diverged branches**.
+   - **Trigger pipelines for mirror updates**.
+   - **Only mirror protected branches**.
 1. Click the **Mirror repository** button to save the configuration.
 ![Repository mirroring pull settings screen - upper part](img/repository_mirroring_pull_settings_upper.png)