Update capitalization in admin, api, others

Update capitalization in /administration, /api, /ci
and /customization

doc/administration/container_registry.md

@@ -471,7 +471,7 @@ You can use GitLab as an auth endpoint and use a non-bundled Container Registry.
    ```
 1. A certificate keypair is required for GitLab and the Container Registry to
-   communicate securely.  By default omnibus-gitlab will generate one keypair,
+   communicate securely.  By default Omnibus GitLab will generate one keypair,
    which is saved to `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key`.
    When using a non-bundled Container Registry, you will need to supply a
    custom certificate key. To do that, add the following to
@@ -487,7 +487,7 @@ You can use GitLab as an auth endpoint and use a non-bundled Container Registry.
    **Note:** The file specified at `registry_key_path` gets populated with the
    content specified by `internal_key`, each time reconfigure is executed. If
-   no file is specified, omnibus-gitlab will default it to
+   no file is specified, Omnibus GitLab will default it to
    `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key` and will populate
    it.

doc/administration/custom_hooks.md

@@ -12,17 +12,17 @@ NOTE: **Note:**
 Custom Git hooks won't be replicated to secondary nodes if you use [GitLab Geo](geo/replication/index.md)
 Git natively supports hooks that are executed on different actions.
-Examples of server-side git hooks include pre-receive, post-receive, and update.
+Examples of server-side Git hooks include pre-receive, post-receive, and update.
 See [Git SCM Server-Side Hooks][hooks] for more information about each hook type.
-As of gitlab-shell version 2.2.0 (which requires GitLab 7.5+), GitLab
-administrators can add custom git hooks to any GitLab project.
+As of GitLab Shell version 2.2.0 (which requires GitLab 7.5+), GitLab
+administrators can add custom Git hooks to any GitLab project.
 ## Create a custom Git hook for a repository
 Server-side Git hooks are typically placed in the repository's `hooks`
-subdirectory. In GitLab, hook directories are symlinked to the gitlab-shell
-`hooks` directory for ease of maintenance between gitlab-shell upgrades.
+subdirectory. In GitLab, hook directories are symlinked to the GitLab Shell
+`hooks` directory for ease of maintenance between GitLab Shell upgrades.
 Custom hooks are implemented differently, but the behavior is exactly the same
 once the hook is created. Follow the steps below to set up a custom hook for a
 repository:
@@ -36,7 +36,7 @@ repository:
 1. Inside the new `custom_hooks` directory, create a file with a name matching
    the hook type. For a pre-receive hook the file name should be `pre-receive`
    with no extension.
-1. Make the hook file executable and make sure it's owned by git.
+1. Make the hook file executable and make sure it's owned by Git.
 1. Write the code to make the Git hook function as expected. Hooks can be
    in any language. Ensure the 'shebang' at the top properly reflects the language
    type. For example, if the script is in Ruby the shebang will probably be
@@ -49,17 +49,17 @@ as appropriate.
 To create a Git hook that applies to all of your repositories in
 your instance, set a global Git hook. Since all the repositories' `hooks`
-directories are symlinked to gitlab-shell's `hooks` directory, adding any hook
-to the gitlab-shell `hooks` directory will also apply it to all repositories. Follow
+directories are symlinked to GitLab Shell's `hooks` directory, adding any hook
+to the GitLab Shell `hooks` directory will also apply it to all repositories. Follow
 the steps below to properly set up a custom hook for all repositories:
 1. On the GitLab server, navigate to the configured custom hook directory. The
-   default is in the gitlab-shell directory. The gitlab-shell `hook` directory
+   default is in the GitLab Shell directory. The GitLab Shell `hook` directory
    for an installation from source the path is usually
    `/home/git/gitlab-shell/hooks`. For Omnibus installs the path is usually
     `/opt/gitlab/embedded/service/gitlab-shell/hooks`.
    To look in a different directory for the global custom hooks,
-   set `custom_hooks_dir` in the gitlab-shell config. For
+   set `custom_hooks_dir` in the GitLab Shell config. For
    Omnibus installations, this can be set in `gitlab.rb`; and in source
    installations, this can be set in `gitlab-shell/config.yml`.
 1. Create a new directory in this location. Depending on your hook, it will be

doc/administration/dependency_proxy.md

@@ -48,7 +48,7 @@ local location or even use object storage.
 The dependency proxy files for Omnibus GitLab installations are stored under
 `/var/opt/gitlab/gitlab-rails/shared/dependency_proxy/` and for source
-installations under `shared/dependency_proxy/` (relative to the git home directory).
+installations under `shared/dependency_proxy/` (relative to the Git home directory).
 To change the local storage path:
 **Omnibus GitLab installations**

doc/administration/git_protocol.md

@@ -53,7 +53,7 @@ sudo service ssh restart
 ## Instructions
 In order to use the new protocol, clients need to either pass the configuration
-`-c protocol.version=2` to the git command, or set it globally:
+`-c protocol.version=2` to the Git command, or set it globally:
 ```sh
 git config --global protocol.version 2

doc/administration/incoming_email.md

@@ -151,7 +151,7 @@ Reply by email should now be working.
 #### Postfix
-Example configuration for Postfix mail server. Assumes mailbox incoming@gitlab.example.com.
+Example configuration for Postfix mail server. Assumes mailbox `incoming@gitlab.example.com`.
 Example for Omnibus installs:
@@ -218,7 +218,7 @@ incoming_email:
 #### Gmail
-Example configuration for Gmail/G Suite. Assumes mailbox gitlab-incoming@gmail.com.
+Example configuration for Gmail/G Suite. Assumes mailbox `gitlab-incoming@gmail.com`.
 Example for Omnibus installs:

doc/administration/index.md

@@ -193,6 +193,6 @@ Learn how to install, configure, update, and maintain your GitLab instance.
   for troubleshooting Kubernetes-related issues.
 - Useful links from the Support Team:
   - [GitLab Developer Docs](https://docs.gitlab.com/ee/development/README.html).
-  - [Repairing and recovering broken git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html).
+  - [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html).
   - [Testing with OpenSSL](https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html).
   - [Strace zine](https://wizardzines.com/zines/strace/).

doc/administration/issue_closing_pattern.md

@@ -13,7 +13,7 @@ in the project's default branch.
 In order to change the pattern you need to have access to the server that GitLab
 is installed on.
-The default pattern can be located in [gitlab.yml.example] under the
+The default pattern can be located in [`gitlab.yml.example`] under the
 "Automatic issue closing" section.
 > **Tip:**

doc/administration/job_artifacts.md

@@ -94,7 +94,7 @@ If you're enabling S3 in [GitLab HA](high_availability/README.md), you will need
 ### Object Storage Settings
-For source installations the following settings are nested under `artifacts:` and then `object_store:`. On omnibus installs they are prefixed by `artifacts_object_store_`.
+For source installations the following settings are nested under `artifacts:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `artifacts_object_store_`.
 | Setting | Description | Default |
 |---------|-------------|---------|

doc/administration/packages.md

@@ -55,7 +55,7 @@ local location or even use object storage.
 The packages for Omnibus GitLab installations are stored under
 `/var/opt/gitlab/gitlab-rails/shared/packages/` and for source
-installations under `shared/packages/` (relative to the git homedir).
+installations under `shared/packages/` (relative to the Git homedir).
 To change the local storage path:
 **Omnibus GitLab installations**

doc/administration/plugins.md

@@ -39,7 +39,7 @@ Follow the steps below to set up a custom hook:
 1. Inside the `plugins` directory, create a file with a name of your choice,
    without spaces or special characters.
-1. Make the hook file executable and make sure it's owned by the git user.
+1. Make the hook file executable and make sure it's owned by the Git user.
 1. Write the code to make the plugin function as expected. That can be
    in any language, and ensure the 'shebang' at the top properly reflects the
    language type. For example, if the script is in Ruby the shebang will

doc/administration/reply_by_email_postfix_setup.md

@@ -18,7 +18,7 @@ The instructions make the assumption that you will be using the email address `i
    sudo apt-get install postfix
    ```
-   When asked about the environment, select 'Internet Site'. When asked to confirm the hostname, make sure it matches gitlab.example.com`.
+   When asked about the environment, select 'Internet Site'. When asked to confirm the hostname, make sure it matches `gitlab.example.com`.
 1. Install the `mailutils` package.

doc/administration/repository_checks.md

@@ -3,7 +3,7 @@
 > [Introduced][ce-3232] in GitLab 8.7. It is OFF by default because it still
 causes too many false alarms.
-Git has a built-in mechanism, [git fsck][git-fsck], to verify the
+Git has a built-in mechanism, [`git fsck`][git-fsck], to verify the
 integrity of all data committed to a repository. GitLab administrators
 can trigger such a check for a project via the project page under the
 admin panel. The checks run asynchronously so it may take a few minutes

doc/administration/repository_storage_types.md

@@ -118,7 +118,7 @@ If you do have any existing integration, you may want to do a small rollout firs
 to validate. You can do so by specifying a range with the operation.
 This is an example of how to limit the rollout to Project IDs 50 to 100, running in
-an Omnibus Gitlab installation:
+an Omnibus GitLab installation:
 ```bash
 sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
@@ -139,7 +139,7 @@ To schedule a complete rollback, see the
 [rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
 The rollback task also supports specifying a range of Project IDs. Here is an example
-of limiting the rollout to Project IDs 50 to 100, in an Omnibus Gitlab installation:
+of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
 ```bash
 sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
@@ -185,7 +185,7 @@ CI Artifacts are S3 compatible since **9.4** (GitLab Premium), and available in
 ##### LFS Objects
-LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following git own implementation:
+LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following Git own implementation:
 ```ruby
 "shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}"

doc/administration/uploads.md

@@ -57,7 +57,7 @@ This configuration relies on valid AWS credentials to be configured already.
 ## Object Storage Settings
-For source installations the following settings are nested under `uploads:` and then `object_store:`. On omnibus installs they are prefixed by `uploads_object_store_`.
+For source installations the following settings are nested under `uploads:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `uploads_object_store_`.
 | Setting | Description | Default |
 |---------|-------------|---------|

doc/api/features.md

@@ -60,8 +60,8 @@ POST /features/:name
 | `value` | integer/string | yes | `true` or `false` to enable/disable, or an integer for percentage of time |
 | `feature_group` | string | no | A Feature group name |
 | `user` | string | no | A GitLab username |
-| `group` | string | no | A GitLab group's path, for example 'gitlab-org' |
-| `project` | string | no | A projects path, for example 'gitlab-org/gitlab-ce' |
+| `group` | string | no | A GitLab group's path, for example `gitlab-org` |
+| `project` | string | no | A projects path, for example `gitlab-org/gitlab-ce` |
 Note that you can enable or disable a feature for a `feature_group`, a `user`,
 a `group`, and a `project` in a single API call.

doc/api/geo_nodes.md

@@ -111,7 +111,7 @@ PUT /geo_nodes/:id
 |-----------------------------|---------|-----------|---------------------------------------------------------------------------|
 | `id`                        | integer | yes       | The ID of the Geo node.                                                   |
 | `enabled`                   | boolean | no        | Flag indicating if the Geo node is enabled.                               |
-| `name`                      | string  | yes       | The unique identifier for the Geo node. Must match `geo_node_name` if it is set in gitlab.rb, otherwise it must match `external_url`. |
+| `name`                      | string  | yes       | The unique identifier for the Geo node. Must match `geo_node_name` if it is set in `gitlab.rb`, otherwise it must match `external_url`. |
 | `url`                       | string  | yes       | The user-facing URL of the Geo node. |
 | `internal_url`              | string  | no        | The URL defined on the primary node that secondary nodes should use to contact it. Returns `url` if not set.|
 | `files_max_capacity`        | integer | no        | Control the maximum concurrency of LFS/attachment backfill for this secondary node. |

doc/api/lint.md

-# Validate the .gitlab-ci.yml (API)
+# Validate the `.gitlab-ci.yml` (API)
 > [Introduced][ce-5953] in GitLab 8.12.
@@ -10,7 +10,7 @@ POST /ci/lint
 | Attribute  | Type    | Required | Description |
 | ---------- | ------- | -------- | -------- |
-| `content`  | string    | yes      | the .gitlab-ci.yaml content|
+| `content`  | string    | yes      | the `.gitlab-ci.yaml` content|
 ```bash
 curl --header "Content-Type: application/json" https://gitlab.example.com/api/v4/ci/lint --data '{"content": "{ \"image\": \"ruby:2.6\", \"services\": [\"postgres\"], \"before_script\": [\"bundle install\", \"bundle exec rake db:create\"], \"variables\": {\"DB_NAME\": \"postgres\"}, \"types\": [\"test\", \"deploy\", \"notify\"], \"rspec\": { \"script\": \"rake spec\", \"tags\": [\"ruby\", \"postgres\"], \"only\": [\"branches\"]}}"}'

doc/api/projects.md

@@ -2037,13 +2037,13 @@ Read more in the [Project Badges](project_badges.md) documentation.
 The non-default [issue and merge request description templates](../user/project/description_templates.md) are managed inside the project's repository. So you can manage them via the API through the [Repositories API](repositories.md) and the [Repository Files API](repository_files.md).
-## Download snapshot of a git repository
+## Download snapshot of a Git repository
 > Introduced in GitLab 10.7
 This endpoint may only be accessed by an administrative user.
-Download a snapshot of the project (or wiki, if requested) git repository. This
+Download a snapshot of the project (or wiki, if requested) Git repository. This
 snapshot is always in uncompressed [tar](https://en.wikipedia.org/wiki/Tar_(computing))
 format.

doc/api/repository_files.md

@@ -246,7 +246,7 @@ error message. Possible causes for a failed commit include:
   user tried to make an empty commit;
 - the branch was updated by a Git push while the file edit was in progress.
-Currently gitlab-shell has a boolean return code, preventing GitLab from specifying the error.
+Currently GitLab Shell has a boolean return code, preventing GitLab from specifying the error.
 ## Delete existing file in repository

doc/api/settings.md

@@ -232,7 +232,7 @@ are listed in the descriptions of the relevant settings.
 | `file_template_project_id`               | integer          | no                                   | **(PREMIUM)** The ID of a project to load custom file templates from |
 | `first_day_of_week`                      | integer          | no                                   | Start day of the week for calendar views and date pickers. Valid values are `0` (default) for Sunday, `1` for Monday, and `6` for Saturday. |
 | `geo_status_timeout`                     | integer          | no                                   | **(PREMIUM)** The amount of seconds after which a request to get a secondary node status will time out. |
-| `gitaly_timeout_default`                 | integer          | no                                   | Default Gitaly timeout, in seconds. This timeout is not enforced for git fetch/push operations or Sidekiq jobs. Set to `0` to disable timeouts. |
+| `gitaly_timeout_default`                 | integer          | no                                   | Default Gitaly timeout, in seconds. This timeout is not enforced for Git fetch/push operations or Sidekiq jobs. Set to `0` to disable timeouts. |
 | `gitaly_timeout_fast`                    | integer          | no                                   | Gitaly fast operation timeout, in seconds. Some Gitaly operations are expected to be fast. If they exceed this threshold, there may be a problem with a storage shard and 'failing fast' can help maintain the stability of the GitLab instance. Set to `0` to disable timeouts. |
 | `gitaly_timeout_medium`                  | integer          | no                                   | Medium Gitaly timeout, in seconds. This should be a value between the Fast and the Default timeout. Set to `0` to disable timeouts. |
 | `gravatar_enabled`                       | boolean          | no                                   | Enable Gravatar. |
@@ -244,7 +244,7 @@ are listed in the descriptions of the relevant settings.
 | `hide_third_party_offers`                | boolean          | no                                   | Do not display offers from third parties within GitLab. |
 | `home_page_url`                          | string           | no                                   | Redirect to this URL when not logged in. |
 | `housekeeping_bitmaps_enabled`           | boolean          | required by: `housekeeping_enabled`  | Enable Git pack file bitmap creation. |
-| `housekeeping_enabled`                   | boolean          | no                                   | (**If enabled, requires:** `housekeeping_bitmaps_enabled`, `housekeeping_full_repack_period`, `housekeeping_gc_period`, and `housekeeping_incremental_repack_period`) Enable or disable git housekeeping. |
+| `housekeeping_enabled`                   | boolean          | no                                   | (**If enabled, requires:** `housekeeping_bitmaps_enabled`, `housekeeping_full_repack_period`, `housekeeping_gc_period`, and `housekeeping_incremental_repack_period`) Enable or disable Git housekeeping. |
 | `housekeeping_full_repack_period`        | integer          | required by: `housekeeping_enabled`  | Number of Git pushes after which an incremental `git repack` is run. |
 | `housekeeping_gc_period`                 | integer          | required by: `housekeeping_enabled`  | Number of Git pushes after which `git gc` is run. |
 | `housekeeping_incremental_repack_period` | integer          | required by: `housekeeping_enabled`  | Number of Git pushes after which an incremental `git repack` is run. |