Add latest changes from gitlab-org/gitlab@master

45 files changed, 646 insertions, 429 deletions

diff --git a/doc/administration/moderate_users.md b/doc/administration/moderate_users.md
index 4e012bdc9bd..b30294c5fe0 100644
--- a/doc/administration/moderate_users.md
+++ b/doc/administration/moderate_users.md
@@ -57,9 +57,7 @@ To approve or reject a user sign up:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Pending approval** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Approve** or **Reject**.
+1. For the user sign up you want to approve or reject, select the vertical ellipsis (**{ellipsis_v}**), then **Approve** or **Reject**.
 
 Approving a user:
 
@@ -88,7 +86,7 @@ To block a user:
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. For the user you want to deactivate, select the vertical ellipsis (**{ellipsis_v}**) and then **Block**.
+1. For the user you want to block, select the vertical ellipsis (**{ellipsis_v}**), then **Block**.
 
 To report abuse from other users, see [report abuse](../user/report_abuse.md). For more information on abuse reports in the Admin area, see [resolving abuse reports](../administration/review_abuse_reports.md#resolving-abuse-reports).
 
@@ -100,9 +98,7 @@ A blocked user can be unblocked from the Admin Area. To do this:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Blocked** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Unblock**.
+1. For the user you want to unblock, select the vertical ellipsis (**{ellipsis_v}**), then **Unblock**.
 
 The user's state is set to active and they consume a
 [seat](../subscriptions/self_managed/index.md#billable-users).
@@ -137,7 +133,7 @@ The user you deactivate must be dormant. When you deactivate a user, their proje
 - Cannot use slash commands. For more information, see [slash commands](../user/project/integrations/gitlab_slack_application.md#slash-commands).
 - Does not occupy a seat. For more information, see [billable users](../subscriptions/self_managed/index.md#billable-users).
 
-Deactiviation is similar to blocking, but there are a few important differences. Deactivating a user does not prohibit the user from signing into the GitLab UI. A deactivated user can become active again by signing in. 
+Deactivation is similar to blocking, but there are a few important differences. Deactivating a user does not prohibit the user from signing into the GitLab UI. A deactivated user can become active again by signing in.
 
 To deactivate a user from the Admin Area:
 
@@ -220,9 +216,7 @@ To do this:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Deactivated** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Activate**.
+1. For the user you want to activate, select the vertical ellipsis (**{ellipsis_v}**), then **Activate**.
 
 The user's state is set to active and they consume a
 [seat](../subscriptions/self_managed/index.md#billable-users).
@@ -250,9 +244,7 @@ Users can be banned using the Admin Area. To do this:
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Ban user**.
+1. For the user you want to ban, select the vertical ellipsis (**{ellipsis_v}**), then **Ban user**.
 
 The banned user does not consume a [seat](../subscriptions/self_managed/index.md#billable-users).
 
@@ -264,24 +256,19 @@ A banned user can be unbanned using the Admin Area. To do this:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Banned** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Unban user**.
+1. For the user you want to unban, select the vertical ellipsis (**{ellipsis_v}**), then **Unban user**.
 
 The user's state is set to active and they consume a
 [seat](../subscriptions/self_managed/index.md#billable-users).
 
-### Delete a user
+## Delete a user
 
 Use the Admin Area to delete users.
 
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. Select the **Banned** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Delete user**.
+1. For the user you want to delete, select the vertical ellipsis (**{ellipsis_v}**), then **Delete user**.
 1. Type the username.
 1. Select **Delete user**.
 
@@ -293,10 +280,7 @@ You can also delete a user and their contributions, such as merge requests, issu
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. Select the **Banned** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Delete user and contributions**.
+1. For the user you want to delete, select the vertical ellipsis (**{ellipsis_v}**), then **Delete user and contributions**.
 1. Type the username.
 1. Select **Delete user and contributions**.
 
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 8f201e0a5ab..731142d4a44 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -214,7 +214,7 @@ See [Recommended cloud providers and services](index.md#recommended-cloud-provid
 
 The reference architectures were tested with repositories of varying sizes that follow best practices.
 
-**However, [large monorepos](../../user/project/repository/managing_large_repositories.md) (several gigabytes or more) can significantly impact the performance of Git and in turn the environment itself.**
+**However, [large monorepos](../../user/project/repository/monorepos/optimize_settings.md) (several gigabytes or more) can significantly impact the performance of Git and in turn the environment itself.**
 Their presence, as well as how they are used, can put a significant strain on the entire system from Gitaly through to the underlying infrastructure.
 
 WARNING:
@@ -223,12 +223,12 @@ If this applies to you, we strongly recommended referring to the linked document
 As such, large monorepos come with notable cost. If you have such a repository we strongly recommend
 the following guidance is followed to ensure the best chance of good performance and to keep costs in check:
 
-- [Optimize the large monorepo](../../user/project/repository/managing_large_repositories.md#optimize-gitlab-settings). Using features such as
-  [LFS](../../user/project/repository/managing_large_repositories.md#use-lfs-for-large-blobs) to not store binaries, and other approaches for reducing repository size, can
+- [Optimize the large monorepo](../../user/project/repository/monorepos/optimize_settings.md#optimize-gitlab-settings). Using features such as
+  [LFS](../../user/project/repository/monorepos/optimize_settings.md#use-lfs-for-large-blobs) to not store binaries, and other approaches for reducing repository size, can
   dramatically improve performance and reduce costs.
 - Depending on the monorepo, increased environment specifications may be required to compensate. Gitaly in particular will likely require additional resources along with Praefect, GitLab Rails, and Load Balancers. This depends notably on the monorepo itself and the usage against it.
 - When the monorepo is significantly large (20 gigabytes or more) further additional strategies maybe required such as even further increased specifications or in some cases a separate Gitaly backend for the monorepo alone.
-- Network and disk bandwidth is another potential consideration with large monorepos. In very heavy cases, it's possible to see bandwidth saturation if there's a high amount of concurrent clones (such as with CI). It's strongly recommended [reducing full clones wherever possible](../../user/project/repository/managing_large_repositories.md#reduce-concurrent-clones-in-cicd) in this scenario. Otherwise, additional environment specifications may be required to increase bandwidth, but this differs between cloud providers.
+- Network and disk bandwidth is another potential consideration with large monorepos. In very heavy cases, it's possible to see bandwidth saturation if there's a high amount of concurrent clones (such as with CI). It's strongly recommended [reducing full clones wherever possible](../../user/project/repository/monorepos/optimize_settings.md#reduce-concurrent-clones-in-cicd) in this scenario. Otherwise, additional environment specifications may be required to increase bandwidth, but this differs between cloud providers.
 
 ### Additional workloads
 
@@ -239,7 +239,7 @@ However, additional workloads can multiply the impact of operations by triggerin
 You may need to adjust the suggested specifications to compensate if you use, for example:
 
 - Security software on the nodes.
-- Hundreds of concurrent CI jobs for [large repositories](../../user/project/repository/managing_large_repositories.md).
+- Hundreds of concurrent CI jobs for [large repositories](../../user/project/repository/monorepos/optimize_settings.md).
 - Custom scripts that [run at high frequency](../logs/log_parsing.md#print-top-api-user-agents).
 - [Integrations](../../integration/index.md) in many large projects.
 - [Server hooks](../server_hooks.md).
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index da9573a8a37..9e0b5fc7e41 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -22027,12 +22027,14 @@ Represents a file or directory in the project repository that has been locked.
 | <a id="pipelineactive"></a>`active` | [`Boolean!`](#boolean) | Indicates if the pipeline is active. |
 | <a id="pipelinebeforesha"></a>`beforeSha` | [`String`](#string) | Base SHA of the source branch. |
 | <a id="pipelinecancelable"></a>`cancelable` | [`Boolean!`](#boolean) | Specifies if a pipeline can be canceled. |
+| <a id="pipelinechild"></a>`child` | [`Boolean!`](#boolean) | If the pipeline is a child or not. |
 | <a id="pipelinecodequalityreportsummary"></a>`codeQualityReportSummary` | [`CodeQualityReportSummary`](#codequalityreportsummary) | Code Quality report summary for a pipeline. |
 | <a id="pipelinecodequalityreports"></a>`codeQualityReports` | [`CodeQualityDegradationConnection`](#codequalitydegradationconnection) | Code Quality degradations reported on the pipeline. (see [Connections](#connections)) |
 | <a id="pipelinecommit"></a>`commit` | [`Commit`](#commit) | Git commit of the pipeline. |
 | <a id="pipelinecommitpath"></a>`commitPath` | [`String`](#string) | Path to the commit that triggered the pipeline. |
 | <a id="pipelinecommittedat"></a>`committedAt` | [`Time`](#time) | Timestamp of the pipeline's commit. |
 | <a id="pipelinecomplete"></a>`complete` | [`Boolean!`](#boolean) | Indicates if a pipeline is complete. |
+| <a id="pipelinecomputeminutes"></a>`computeMinutes` | [`Float`](#float) | Total minutes consumed by the pipeline. |
 | <a id="pipelineconfigsource"></a>`configSource` | [`PipelineConfigSourceEnum`](#pipelineconfigsourceenum) | Configuration source of the pipeline (UNKNOWN_SOURCE, REPOSITORY_SOURCE, AUTO_DEVOPS_SOURCE, WEBIDE_SOURCE, REMOTE_SOURCE, EXTERNAL_PROJECT_SOURCE, BRIDGE_SOURCE, PARAMETER_SOURCE, COMPLIANCE_SOURCE, SECURITY_POLICIES_DEFAULT_SOURCE). |
 | <a id="pipelinecoverage"></a>`coverage` | [`Float`](#float) | Coverage percentage. |
 | <a id="pipelinecreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp of the pipeline's creation. |
@@ -22040,10 +22042,13 @@ Represents a file or directory in the project repository that has been locked.
 | <a id="pipelinedetailedstatus"></a>`detailedStatus` | [`DetailedStatus!`](#detailedstatus) | Detailed status of the pipeline. |
 | <a id="pipelinedownstream"></a>`downstream` | [`PipelineConnection`](#pipelineconnection) | Pipelines this pipeline will trigger. (see [Connections](#connections)) |
 | <a id="pipelineduration"></a>`duration` | [`Int`](#int) | Duration of the pipeline in seconds. |
+| <a id="pipelinefailurereason"></a>`failureReason` | [`String`](#string) | The reason why the pipeline failed. |
 | <a id="pipelinefinishedat"></a>`finishedAt` | [`Time`](#time) | Timestamp of the pipeline's completion. |
 | <a id="pipelineid"></a>`id` | [`ID!`](#id) | ID of the pipeline. |
 | <a id="pipelineiid"></a>`iid` | [`String!`](#string) | Internal ID of the pipeline. |
 | <a id="pipelinejobartifacts"></a>`jobArtifacts` | [`[CiJobArtifact!]`](#cijobartifact) | Job artifacts of the pipeline. |
+| <a id="pipelinelatest"></a>`latest` | [`Boolean!`](#boolean) | If the pipeline is the latest one or not. |
+| <a id="pipelinemergerequest"></a>`mergeRequest` | [`MergeRequest`](#mergerequest) | The MR which the Pipeline is attached to. |
 | <a id="pipelinemergerequesteventtype"></a>`mergeRequestEventType` | [`PipelineMergeRequestEventType`](#pipelinemergerequesteventtype) | Event type of the pipeline associated with a merge request. |
 | <a id="pipelinename"></a>`name` | [`String`](#string) | Name of the pipeline. |
 | <a id="pipelinepath"></a>`path` | [`String`](#string) | Relative path to the pipeline's page. |
@@ -22051,13 +22056,18 @@ Represents a file or directory in the project repository that has been locked.
 | <a id="pipelinequeuedduration"></a>`queuedDuration` | [`Duration`](#duration) | How long the pipeline was queued before starting. |
 | <a id="pipelineref"></a>`ref` | [`String`](#string) | Reference to the branch from which the pipeline was triggered. |
 | <a id="pipelinerefpath"></a>`refPath` | [`String`](#string) | Reference path to the branch from which the pipeline was triggered. |
+| <a id="pipelinereftext"></a>`refText` | [`String!`](#string) | The reference text from the presenter. |
 | <a id="pipelineretryable"></a>`retryable` | [`Boolean!`](#boolean) | Specifies if a pipeline can be retried. |
 | <a id="pipelinesecurityreportsummary"></a>`securityReportSummary` | [`SecurityReportSummary`](#securityreportsummary) | Vulnerability and scanned resource counts for each security scanner of the pipeline. |
+| <a id="pipelinesource"></a>`source` | [`String`](#string) | The source of the pipeline. |
 | <a id="pipelinesourcejob"></a>`sourceJob` | [`CiJob`](#cijob) | Job where pipeline was triggered from. |
 | <a id="pipelinestages"></a>`stages` | [`CiStageConnection`](#cistageconnection) | Stages of the pipeline. (see [Connections](#connections)) |
 | <a id="pipelinestartedat"></a>`startedAt` | [`Time`](#time) | Timestamp when the pipeline was started. |
 | <a id="pipelinestatus"></a>`status` | [`PipelineStatusEnum!`](#pipelinestatusenum) | Status of the pipeline (CREATED, WAITING_FOR_RESOURCE, PREPARING, PENDING, RUNNING, FAILED, SUCCESS, CANCELED, SKIPPED, MANUAL, SCHEDULED). |
+| <a id="pipelinestuck"></a>`stuck` | [`Boolean!`](#boolean) | If the pipeline is stuck. |
 | <a id="pipelinetestreportsummary"></a>`testReportSummary` | [`TestReportSummary!`](#testreportsummary) | Summary of the test report generated by the pipeline. |
+| <a id="pipelinetotaljobs"></a>`totalJobs` | [`Int!`](#int) | The total number of jobs in the pipeline. |
+| <a id="pipelinetriggeredbypath"></a>`triggeredByPath` | [`String`](#string) | The path that triggered this pipeline. |
 | <a id="pipelineupdatedat"></a>`updatedAt` | [`Time!`](#time) | Timestamp of the pipeline's last activity. |
 | <a id="pipelineupstream"></a>`upstream` | [`Pipeline`](#pipeline) | Pipeline that triggered the pipeline. |
 | <a id="pipelineuser"></a>`user` | [`UserCore`](#usercore) | Pipeline user. |
diff --git a/doc/api/integrations.md b/doc/api/integrations.md
index 35ec97ced05..d3e8540f7b2 100644
--- a/doc/api/integrations.md
+++ b/doc/api/integrations.md
@@ -1457,6 +1457,7 @@ Parameters:
 | `token`   | string | true | The Telegram bot token (for example, `123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11`). |
 | `room` | string | true | Unique identifier for the target chat or the username of the target channel (in the format `@channelusername`). |
 | `notify_only_broken_pipelines` | boolean | false | Send notifications for broken pipelines. |
+| `branches_to_be_notified` | string | false | Branches to send notifications for ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134361) in GitLab 16.5). Valid options are `all`, `default`, `protected`, and `default_and_protected`. The default value is `default`. |
 | `push_events` | boolean | true | Enable notifications for push events. |
 | `issues_events` | boolean | true | Enable notifications for issue events. |
 | `confidential_issues_events` | boolean | true | Enable notifications for confidential issue events. |
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 02559da75a0..8748afe7bfa 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -169,7 +169,7 @@ You can choose how your repository is fetched from GitLab when a job runs.
      for every job. However, the local working copy is always pristine.
    - `git fetch` is faster because it re-uses the local working copy (and falls
      back to clone if it doesn't exist). This is recommended, especially for
-     [large repositories](../../user/project/repository/managing_large_repositories.md#git-strategy).
+     [large repositories](../../user/project/repository/monorepos/optimize_settings.md#git-strategy).
 
 The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
 in the `.gitlab-ci.yml` file.
@@ -192,7 +192,7 @@ a repository.
 In GitLab versions 14.7 and later, newly created projects have a default `git depth`
 value of `20`. GitLab versions 14.6 and earlier have a default `git depth` value of `50`.
 
-This value can be overridden by the [`GIT_DEPTH` variable](../../user/project/repository/managing_large_repositories.md#shallow-cloning)
+This value can be overridden by the [`GIT_DEPTH` variable](../../user/project/repository/monorepos/optimize_settings.md#shallow-cloning)
 in the `.gitlab-ci.yml` file.
 
 ## Set a limit for how long jobs can run
diff --git a/doc/development/backend/ruby_style_guide.md b/doc/development/backend/ruby_style_guide.md
index d239d7bbf49..384d8122ccf 100644
--- a/doc/development/backend/ruby_style_guide.md
+++ b/doc/development/backend/ruby_style_guide.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index bc6ec96cf49..c4ec0f66b62 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/first_contribution.md b/doc/development/contributing/first_contribution.md
index 0c21ad60951..3477590f40b 100644
--- a/doc/development/contributing/first_contribution.md
+++ b/doc/development/contributing/first_contribution.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 54eeaefefd5..abec161bd6e 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 0f8341ea623..0b1c7303fc0 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index b0794f96f9b..e739799557e 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 651c7214275..80ac0b872d6 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md
index e94b7583904..8d1bd3c76f0 100644
--- a/doc/development/contributing/verify/index.md
+++ b/doc/development/contributing/verify/index.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
-stage: none
-group: Verify
+stage: Verify
+group: Pipeline Execution
 ---
 
 # Contribute to Verify stage codebase
diff --git a/doc/development/development_processes.md b/doc/development/development_processes.md
index 4ce9df8d7da..1cdf667a35f 100644
--- a/doc/development/development_processes.md
+++ b/doc/development/development_processes.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/documentation/graphql_styleguide.md b/doc/development/documentation/graphql_styleguide.md
index 79fcfc7e3f0..3c96dd06b25 100644
--- a/doc/development/documentation/graphql_styleguide.md
+++ b/doc/development/documentation/graphql_styleguide.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 description: "Writing styles, markup, formatting, and other standards for GraphQL API's GitLab Documentation."
 ---
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index 860bc8790e2..ad2cbee974b 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 description: 'Writing styles, markup, formatting, and other standards for GitLab Documentation.'
 ---
diff --git a/doc/development/documentation/topic_types/concept.md b/doc/development/documentation/topic_types/concept.md
index c9aedf940a2..50220b9bebe 100644
--- a/doc/development/documentation/topic_types/concept.md
+++ b/doc/development/documentation/topic_types/concept.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/documentation/topic_types/glossary.md b/doc/development/documentation/topic_types/glossary.md
index 4985101a391..f6137953cb0 100644
--- a/doc/development/documentation/topic_types/glossary.md
+++ b/doc/development/documentation/topic_types/glossary.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/documentation/topic_types/index.md b/doc/development/documentation/topic_types/index.md
index 40039ca5b1a..10e7e3d2014 100644
--- a/doc/development/documentation/topic_types/index.md
+++ b/doc/development/documentation/topic_types/index.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/documentation/topic_types/reference.md b/doc/development/documentation/topic_types/reference.md
index 8bb89f4c210..ef2ca2f791d 100644
--- a/doc/development/documentation/topic_types/reference.md
+++ b/doc/development/documentation/topic_types/reference.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/documentation/topic_types/task.md b/doc/development/documentation/topic_types/task.md
index 7fb4201ac40..a6e4c01505d 100644
--- a/doc/development/documentation/topic_types/task.md
+++ b/doc/development/documentation/topic_types/task.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/documentation/topic_types/troubleshooting.md b/doc/development/documentation/topic_types/troubleshooting.md
index 4b23117acdb..a2fe6f8ca2d 100644
--- a/doc/development/documentation/topic_types/troubleshooting.md
+++ b/doc/development/documentation/topic_types/troubleshooting.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/documentation/topic_types/tutorial.md b/doc/development/documentation/topic_types/tutorial.md
index 9a8d1db5e3e..50976149cf8 100644
--- a/doc/development/documentation/topic_types/tutorial.md
+++ b/doc/development/documentation/topic_types/tutorial.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Style Guide
+group: Documentation Guidelines
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 27497f7d994..10943b2d135 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -18,7 +18,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
   [EE features list](https://about.gitlab.com/features/).
 <!-- markdownlint-enable MD044 -->
 
-## SaaS only feature
+## SaaS-only feature
 
 Use the following guidelines when you develop a feature that is only applicable for SaaS (for example, a CustomersDot integration).
 
@@ -27,14 +27,14 @@ However, there are cases when a feature should only be available on SaaS and thi
 accomplished.
 
 It is recommended you use `Gitlab::Saas.feature_available?`. This enables
-context rich definitions around the reason the feature is SaaS only.
+context rich definitions around the reason the feature is SaaS-only.
 
-### Implementing a SaaS only feature with `Gitlab::Saas.feature_available?`
+### Implementing a SaaS-only feature with `Gitlab::Saas.feature_available?`
 
 #### Adding to the FEATURES constant
 
 1. See the [namespacing concepts guide](software_design.md#use-namespaces-to-define-bounded-contexts)
-   for help in naming a new SaaS only feature.
+   for help in naming a new SaaS-only feature.
 1. Add the new feature to `FEATURE` in `ee/lib/ee/gitlab/saas.rb`.
 
    ```ruby
@@ -43,7 +43,7 @@ context rich definitions around the reason the feature is SaaS only.
 
 1. Use the new feature in code with `Gitlab::Saas.feature_available?('some_domain/new_feature_name')`.
 
-#### SaaS only feature definition and validation
+#### SaaS-only feature definition and validation
 
 This process is meant to ensure consistent SaaS feature usage in the codebase. All SaaS features **must**:
 
@@ -63,7 +63,7 @@ Each SaaS feature is defined in a separate YAML file consisting of a number of f
 | `milestone`         | no       | Milestone in which the SaaS feature was created.                                                             |
 | `group`             | no       | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
 
-### Opting out of a SaaS only feature on another SaaS instance (JiHu)
+### Opting out of a SaaS-only feature on another SaaS instance (JiHu)
 
 Prepend the `ee/lib/ee/gitlab/saas.rb` module and override the `Gitlab::Saas.feature_available?` method.
 
@@ -76,11 +76,46 @@ def feature_available?(feature)
 end
 ```
 
-### Do not use SaaS only features for functionality in CE
+### Do not use SaaS-only features for functionality in CE
 
 `Gitlab::Saas.feature_vailable?` must not appear in CE.
 See [extending CE with EE guide](#extend-ce-features-with-ee-backend-code).
 
+### SaaS-only features in tests
+
+Introducing a SaaS-only feature into the codebase creates an additional code path that should be tested.
+It is strongly advised to include automated tests for all code affected by a SaaS-only feature, both when **enabled** and **disabled**
+to ensure the feature works properly.
+
+To enable a SaaS-only feature in a test, use the `stub_saas_features`
+helper. For example, to globally disable the `purchases/additional_minutes` feature
+flag in a test:
+
+```ruby
+stub_saas_features('purchases/additional_minutes' => false)
+
+::Gitlab::Saas.feature_available?('purchases/additional_minutes') # => false
+```
+
+A common pattern of testing both paths looks like:
+
+```ruby
+it 'purchases/additional_minutes is not available' do
+  # tests assuming purchases/additional_minutes is not enabled by default
+  ::Gitlab::Saas.feature_available?('purchases/additional_minutes') # => false
+end
+
+context 'when purchases/additional_minutes is available' do
+  before do
+    stub_saas_features('purchases/additional_minutes' => true)
+  end
+
+  it 'returns true' do
+    ::Gitlab::Saas.feature_available?('purchases/additional_minutes') # => true
+  end
+end
+```
+
 ### Simulate a SaaS instance
 
 If you're developing locally and need your instance to simulate the SaaS (GitLab.com)
diff --git a/doc/development/fe_guide/dark_mode.md b/doc/development/fe_guide/dark_mode.md
index 144418f72cd..185bd60dd9a 100644
--- a/doc/development/fe_guide/dark_mode.md
+++ b/doc/development/fe_guide/dark_mode.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/fe_guide/design_tokens.md b/doc/development/fe_guide/design_tokens.md
index 78219809b05..b47c2661e19 100644
--- a/doc/development/fe_guide/design_tokens.md
+++ b/doc/development/fe_guide/design_tokens.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 2b3a5ea8bfd..99070f3d31c 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/feature_development.md b/doc/development/feature_development.md
index b1994f446cc..4dbde42b0ff 100644
--- a/doc/development/feature_development.md
+++ b/doc/development/feature_development.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index 79e04544c34..6c46780a5d7 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index f966395edb4..552a4ccc84b 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/index.md b/doc/development/index.md
index 55e594c537a..71ab54c8a73 100644
--- a/doc/development/index.md
+++ b/doc/development/index.md
@@ -1,7 +1,7 @@
 ---
 type: index, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 description: "Development Guidelines: learn how to contribute to GitLab."
 ---
diff --git a/doc/development/internal_users.md b/doc/development/internal_users.md
index cf45cf941d0..2b809137906 100644
--- a/doc/development/internal_users.md
+++ b/doc/development/internal_users.md
@@ -2,7 +2,7 @@
 description: "Internal users documentation."
 type: concepts, reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/labels/index.md b/doc/development/labels/index.md
index dfd2a9e4fd3..c2caabda109 100644
--- a/doc/development/labels/index.md
+++ b/doc/development/labels/index.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/packages/harbor_registry_development.md b/doc/development/packages/harbor_registry_development.md
index dc97ecfa7b2..609aba9251c 100644
--- a/doc/development/packages/harbor_registry_development.md
+++ b/doc/development/packages/harbor_registry_development.md
@@ -1,6 +1,6 @@
 ---
 stage: Package
-group: Harbor Registry
+group: Container Registry
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 # Harbor Registry
diff --git a/doc/development/rubocop_development_guide.md b/doc/development/rubocop_development_guide.md
index f6c11a0c7e3..6568d025ca5 100644
--- a/doc/development/rubocop_development_guide.md
+++ b/doc/development/rubocop_development_guide.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index e2c0e3156eb..180d35e04fe 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 ---
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 89e2442e33c..dbee7acac69 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -1,7 +1,7 @@
 ---
 type: reference, dev
 stage: none
-group: Development
+group: unassigned
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 description: "GitLab development guidelines - testing best practices."
 ---
diff --git a/doc/development/testing_guide/contract/consumer_tests.md b/doc/development/testing_guide/contract/consumer_tests.md
index 60ce71db79d..4a84dafdcf2 100644
--- a/doc/development/testing_guide/contract/consumer_tests.md
+++ b/doc/development/testing_guide/contract/consumer_tests.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/testing_guide/contract/index.md b/doc/development/testing_guide/contract/index.md
index 577699fa828..45933e9cb4f 100644
--- a/doc/development/testing_guide/contract/index.md
+++ b/doc/development/testing_guide/contract/index.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/testing_guide/contract/provider_tests.md b/doc/development/testing_guide/contract/provider_tests.md
index 71940941d51..86ac6518d2f 100644
--- a/doc/development/testing_guide/contract/provider_tests.md
+++ b/doc/development/testing_guide/contract/provider_tests.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md
index ab4dd9acb63..8cf1a46d5d2 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -1,6 +1,6 @@
 ---
 stage: none
-group: Development
+group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
diff --git a/doc/topics/git/troubleshooting_git.md b/doc/topics/git/troubleshooting_git.md
index 0cc7259a104..ea9bd1f398f 100644
--- a/doc/topics/git/troubleshooting_git.md
+++ b/doc/topics/git/troubleshooting_git.md
@@ -197,7 +197,7 @@ The root causes vary, so multiple potential solutions exist, and you may need to
 apply more than one:
 
 - If this error occurs when cloning a large repository, you can
-  [decrease the cloning depth](../../user/project/repository/managing_large_repositories.md#shallow-cloning)
+  [decrease the cloning depth](../../user/project/repository/monorepos/optimize_settings.md#shallow-cloning)
   to a value of `1`. For example:
 
   ```shell
diff --git a/doc/user/project/repository/managing_large_repositories.md b/doc/user/project/repository/managing_large_repositories.md
index 721150f958b..79660b3e0ac 100644
--- a/doc/user/project/repository/managing_large_repositories.md
+++ b/doc/user/project/repository/managing_large_repositories.md
@@ -1,356 +1,11 @@
 ---
-stage: Systems
-group: Gitaly
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: 'monorepos/optimize_settings.md'
+remove_date: '2023-12-17'
 ---
 
-# Managing monorepos
+This document was moved to [another location](monorepos/optimize_settings.md).
 
-Monorepos have become a regular part of development team workflows. While they have many advantages, monorepos can present performance challenges
-when using them in GitLab. Therefore, you should know:
-
-- What repository characteristics can impact performance.
-- Some tools and steps to optimize monorepos.
-
-## Impact on performance
-
-Because GitLab is a Git-based system, it is subject to similar performance
-constraints as Git when it comes to large repositories that are gigabytes in
-size.
-
-Monorepos can be large for [many reasons](https://about.gitlab.com/blog/2022/09/06/speed-up-your-monorepo-workflow-in-git/#characteristics-of-monorepos).
-
-Large repositories pose a performance risk performance when used in GitLab, especially if a large monorepo receives many clones or pushes a day, which is common for them.
-
-Git itself has performance limitations when it comes to handling
-monorepos.
-
-Monorepos can also impact notably on hardware, in some cases hitting limitations such as vertical scaling and network or disk bandwidth limits.
-
-[Gitaly](https://gitlab.com/gitlab-org/gitaly) is our Git storage service built
-on top of [Git](https://git-scm.com/). This means that any limitations of
-Git are experienced in Gitaly, and in turn by end users of GitLab.
-
-## Optimize GitLab settings
-
-You should use as many of the following strategies as possible to minimize
-fetches on the Gitaly server.
-
-### Rationale
-
-The most resource intensive operation in Git is the
-[`git-pack-objects`](https://git-scm.com/docs/git-pack-objects) process. It is
-responsible for figuring out all of the commit history and files to send back to
-the client.
-
-The larger the repository, the more commits, files, branches, and tags that a
-repository has and the more expensive this operation is. Both memory and CPU
-are heavily utilized during this operation.
-
-Most `git clone` or `git fetch` traffic (which results in starting a `git-pack-objects` process on the server) often come from automated
-continuous integration systems such as GitLab CI/CD or other CI/CD systems.
-If there is a high amount of such traffic, hitting a Gitaly server with many
-clones for a large repository is likely to put the server under significant
-strain.
-
-### Gitaly pack-objects cache
-
-Turn on the [Gitaly pack-objects cache](../../../administration/gitaly/configure_gitaly.md#pack-objects-cache),
-which reduces the work that the server has to do for clones and fetches.
-
-#### Rationale
-
-The [pack-objects cache](../../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
-caches the data that the `git-pack-objects` process produces. This response
-is sent back to the Git client initiating the clone or fetch. If several
-fetches are requesting the same set of refs, Git on the Gitaly server doesn't have
-to re-generate the response data with each clone or fetch call, but instead serves
-that data from an in-memory cache that Gitaly maintains.
-
-This can help immensely in the presence of a high rate of clones for a single
-repository.
-
-For more information, see [Pack-objects cache](../../../administration/gitaly/configure_gitaly.md#pack-objects-cache).
-
-### Reduce concurrent clones in CI/CD
-
-CI/CD loads tend to be concurrent because pipelines are scheduled during set times.
-As a result, the Git requests against the repositories can spike notably during
-these times and lead to reduced performance for both CI/CD and users alike.
-
-Reduce CI/CD pipeline concurrency by staggering them to run at different times.
-For example, a set running at one time and another set running several minutes
-later.
-
-### Shallow cloning
-
-In your CI/CD systems, set the
-[`--depth`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt)
-option in the `git clone` or `git fetch` call.
-
-GitLab and GitLab Runner perform a [shallow clone](../../../ci/pipelines/settings.md#limit-the-number-of-changes-fetched-during-clone)
-by default.
-
-If possible, set the clone depth with a small number like 10. Shallow clones make Git request only
-the latest set of changes for a given branch, up to desired number of commits.
-
-This significantly speeds up fetching of changes from Git repositories,
-especially if the repository has a very long backlog consisting of a number
-of big files because we effectively reduce amount of data transfer.
-
-The following GitLab CI/CD pipeline configuration example sets the `GIT_DEPTH`.
-
-```yaml
-variables:
-  GIT_DEPTH: 10
-
-test:
-  script:
-    - ls -al
-```
-
-### Git strategy
-
-Use `git fetch` instead of `git clone` on CI/CD systems if it's possible to keep
-a working copy of the repository.
-
-By default, GitLab is configured to use the [`fetch` Git strategy](../../../ci/runners/configure_runners.md#git-strategy),
-which is recommended for large repositories.
-
-#### Rationale
-
-`git clone` gets the entire repository from scratch, whereas `git fetch` only
-asks the server for references that do not already exist in the repository.
-Naturally, `git fetch` causes the server to do less work. `git-pack-objects`
-doesn't have to go through all branches and tags and roll everything up into a
-response that gets sent over. Instead, it only has to worry about a subset of
-references to pack up. This strategy also reduces the amount of data to transfer.
-
-### Git clone path
-
-[`GIT_CLONE_PATH`](../../../ci/runners/configure_runners.md#custom-build-directories) allows you to
-control where you clone your repositories. This can have implications if you
-heavily use big repositories with a fork-based workflow.
-
-A fork, from the perspective of GitLab Runner, is stored as a separate repository
-with a separate worktree. That means that GitLab Runner cannot optimize the usage
-of worktrees and you might have to instruct GitLab Runner to use that.
-
-In such cases, ideally you want to make the GitLab Runner executor be used only
-for the given project and not shared across different projects to make this
-process more efficient.
-
-The [`GIT_CLONE_PATH`](../../../ci/runners/configure_runners.md#custom-build-directories) must be
-in the directory set in `$CI_BUILDS_DIR`. You can't pick any path from disk.
-
-### Git clean flags
-
-[`GIT_CLEAN_FLAGS`](../../../ci/runners/configure_runners.md#git-clean-flags) allows you to control
-whether or not you require the `git clean` command to be executed for each CI/CD
-job. By default, GitLab ensures that:
-
-- You have your worktree on the given SHA.
-- Your repository is clean.
-
-[`GIT_CLEAN_FLAGS`](../../../ci/runners/configure_runners.md#git-clean-flags) is disabled when set
-to `none`. On very big repositories, this might be desired because `git
-clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
--e .build/` (for example) allows you to control and disable removal of some
-directories in the worktree between subsequent runs, which can speed-up
-the incremental builds. This has the biggest effect if you re-use existing
-machines and have an existing worktree that you can re-use for builds.
-
-For exact parameters accepted by
-[`GIT_CLEAN_FLAGS`](../../../ci/runners/configure_runners.md#git-clean-flags), see the documentation
-for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
-are dependent on the Git version.
-
-### Git fetch extra flags
-
-[`GIT_FETCH_EXTRA_FLAGS`](../../../ci/runners/configure_runners.md#git-fetch-extra-flags) allows you
-to modify `git fetch` behavior by passing extra flags.
-
-For example, if your project contains a large number of tags that your CI/CD jobs don't rely on,
-you could add [`--no-tags`](https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---no-tags)
-to the extra flags to make your fetches faster and more compact.
-
-Also in the case where you repository does _not_ contain a lot of
-tags, `--no-tags` can [make a big difference in some cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
-If your CI/CD builds do not depend on Git tags, setting `--no-tags` is worth trying.
-
-For more information, see the [`GIT_FETCH_EXTRA_FLAGS` documentation](../../../ci/runners/configure_runners.md#git-fetch-extra-flags).
-
-### Configure Gitaly negotiation timeouts
-
-You might experience a `fatal: the remote end hung up unexpectedly` error when attempting to fetch or archive:
-
-- Large repositories.
-- Many repositories in parallel.
-- The same large repository in parallel.
-
-You can attempt to mitigate this issue by increasing the default negotiation timeout values. For more information, see
-[Configure negotiation timeouts](../../../administration/gitaly/configure_gitaly.md#configure-negotiation-timeouts).
-
-## Optimize your repository
-
-Another avenue to keeping GitLab scalable with your monorepo is to optimize the
-repository itself.
-
-### Profiling repositories
-
-Large repositories generally experience performance issues in Git. Knowing why
-your repository is large can help you develop mitigation strategies to avoid
-performance problems.
-
-You can use [`git-sizer`](https://github.com/github/git-sizer) to get a snapshot
-of repository characteristics and discover problem aspects of your monorepo.
-
-For example:
-
-```shell
-Processing blobs: 1652370
-Processing trees: 3396199
-Processing commits: 722647
-Matching commits to trees: 722647
-Processing annotated tags: 534
-Processing references: 539
-| Name                         | Value     | Level of concern               |
-| ---------------------------- | --------- | ------------------------------ |
-| Overall repository size      |           |                                |
-| * Commits                    |           |                                |
-|   * Count                    |   723 k   | *                              |
-|   * Total size               |   525 MiB | **                             |
-| * Trees                      |           |                                |
-|   * Count                    |  3.40 M   | **                             |
-|   * Total size               |  9.00 GiB | ****                           |
-|   * Total tree entries       |   264 M   | *****                          |
-| * Blobs                      |           |                                |
-|   * Count                    |  1.65 M   | *                              |
-|   * Total size               |  55.8 GiB | *****                          |
-| * Annotated tags             |           |                                |
-|   * Count                    |   534     |                                |
-| * References                 |           |                                |
-|   * Count                    |   539     |                                |
-|                              |           |                                |
-| Biggest objects              |           |                                |
-| * Commits                    |           |                                |
-|   * Maximum size         [1] |  72.7 KiB | *                              |
-|   * Maximum parents      [2] |    66     | ******                         |
-| * Trees                      |           |                                |
-|   * Maximum entries      [3] |  1.68 k   | *                              |
-| * Blobs                      |           |                                |
-|   * Maximum size         [4] |  13.5 MiB | *                              |
-|                              |           |                                |
-| History structure            |           |                                |
-| * Maximum history depth      |   136 k   |                                |
-| * Maximum tag depth      [5] |     1     |                                |
-|                              |           |                                |
-| Biggest checkouts            |           |                                |
-| * Number of directories  [6] |  4.38 k   | **                             |
-| * Maximum path depth     [7] |    13     | *                              |
-| * Maximum path length    [8] |   134 B   | *                              |
-| * Number of files        [9] |  62.3 k   | *                              |
-| * Total size of files    [9] |   747 MiB |                                |
-| * Number of symlinks    [10] |    40     |                                |
-| * Number of submodules       |     0     |                                |
-```
-
-In this example, a few items are raised with a high level of concern. See the
-following sections for information on solving:
-
-- A large number of references.
-- Large blobs.
-
-### Large number of references
-
-[References in Git](https://git-scm.com/book/en/v2/Git-Internals-Git-References)
-are branch and tag names that point to a particular commit. You can use the `git
-for-each-ref` command to list all references present in a repository. A large
-number of references in a repository can have detrimental impact on the command's
-performance. To understand why, we need to understand how Git stores references
-and uses them.
-
-In general, Git stores all references as loose files in the `.git/refs` folder of
-the repository. As the number of references grows, the seek time to find a
-particular reference in the folder also increases. Therefore, every time Git has
-to parse a reference, there is an increased latency due to the added seek time
-of the file system.
-
-To resolve this issue, Git uses [pack-refs](https://git-scm.com/docs/git-pack-refs). In short, instead of storing each
-reference in a single file, Git creates a single `.git/packed-refs` file that
-contains all the references for that repository. This file reduces storage space
-while also increasing performance because seeking within a single file is faster
-than seeking a file within a directory. However, creating and updating new references
-is still done through loose files and are not added to the `packed-refs` file. To
-recreate the `packed-refs` file, run `git pack-refs`.
-
-Gitaly runs `git pack-refs` during [housekeeping](../../../administration/housekeeping.md#heuristical-housekeeping)
-to move loose references into `packed-refs` files. While this is very beneficial
-for most repositories, write-heavy repositories still have the problem that:
-
-- Creating or updating references creates new loose files.
-- Deleting references involves modifying the existing `packed-refs` file
-  altogether to remove the existing reference.
-
-These problems still cause the same performance issues.
-
-In addition, fetches and clones from repositories includes the transfer
-of missing objects from the server to the client. When there are numerous
-references, Git iterates over all references and walks the internal graph
-structure for each reference to find the missing objects to transfer to
-the client. Iteration and walking are CPU-intensive operations that increase
-the latency of these commands.
-
-In repositories with a lot of activity, this often causes a domino effect because
-every operation is slower and each operation stalls subsequent operations.
-
-#### Mitigation strategies
-
-To mitigate the effects of a large number of references in a monorepo:
-
-- Create an automated process for cleaning up old branches.
-- If certain references don't need to be visible to the client, hide them using the
-  [`transfer.hideRefs`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-transferhideRefs)
-  configuration setting. Because Gitaly ignores any on-server Git configuration, you must change the Gitaly configuration
-  itself in `/etc/gitlab/gitlab.rb`:
-
-  ```ruby
-  gitaly['configuration'] = {
-    # ...
-    git: {
-      # ...
-      config: [
-        # ...
-        { key: "transfer.hideRefs", value: "refs/namespace_to_hide" },
-      ],
-    },
-  }
-  ```
-
-In Git 2.42.0 and later, different Git operations can skip over hidden references
-when doing an object graph walk.
-
-### Large blobs
-
-The presence of large files (called blobs in Git), can be problematic for Git
-because it does not handle large binary files efficiently. If there are blobs over
-10 MB or instance in the `git-sizer` output, this probably means there is binary
-data in your repository.
-
-#### Use LFS for large blobs
-
-Store binary or blob files (for example, packages, audio, video, or graphics)
-as Large File Storage (LFS) objects. With LFS, the objects are stored externally, such as in Object
-Storage, which reduces the number and size of objects in the repository. Storing
-objects in external Object Storage can improve performance.
-
-For more information, refer to the [Git LFS documentation](../../../topics/git/lfs/index.md).
-
-### Reference architectures
-
-Large repositories tend to be found in larger organisations with many users. The
-GitLab Quality Engineering and Support teams provide several [reference architectures](../../../administration/reference_architectures/index.md) that
-are the recommended way to deploy GitLab at scale.
-
-In these types of setups, the GitLab environment used should match a reference
-architecture to improve performance.
+<!-- This redirect file can be deleted after <2023-12-17>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/repository/monorepos/observability.md b/doc/user/project/repository/monorepos/observability.md
new file mode 100644
index 00000000000..a54b4bef9d5
--- /dev/null
+++ b/doc/user/project/repository/monorepos/observability.md
@@ -0,0 +1,176 @@
+---
+stage: Systems
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Metrics for measuring monorepo performance
+
+The following metrics can be used to measure server side performance of your
+monorepo. These metrics are not limited to monorepo performance and are more
+general metrics to measure Gitaly performance, but they are especially relevant
+when running a monorepo.
+
+## Clones and Fetches
+
+The most frequent expensive operation are clones and fetches. When taken as a
+percentage of system resources consumed, these operations often contribute to
+90% or more of system resources on Gitaly nodes. Here are some logs and metrics
+that can provide useful signals.
+
+### CPU and Memory
+
+There are two main RPCs that handle clones/fetches. The following log entry
+fields an be used to inspect how much system resources are consumed by
+clones/fetches for a given repository.
+
+The following are log entry fields in the Gitaly logs that can be filtered on:
+
+| Log field        | Values to filter on | Why?                                                                                          |
+|------------------|---------------------|-----------------------------------------------------------------------------------------------|
+| `json.grpc.method` | `PostReceivePack`     | This is the RPC that handles HTTP clones/fetches                                              |
+| `json.grpc.method` | SSHReceivePack      | This is the RPC that handles SSH clones/fetches                                               |
+| `json.grpc.code`   | OK                  | Indicates the RPC has successfully served its request                                         |
+| `json.grpc.code`   | Canceled            | Often times indicates the client killed the connection, usually due to a timeout of some sort |
+| `json.grpc.code`   | ResourceExhausted   | Indicates there are too many Git processes being spawned on the machine simultaneously        |
+| `json.user_id`     | A `user_id` who initiated the clone/fetch. This is in the form of `user-<user_id>` eg: `user-22345`  | Indicates there are too many Git processes being spawned on the machine simultaneously        |
+| `json.username`     | A username who initiated the clone/fetch. eg: `ilovecoding` | In order to see how many clones/fetches were from a given user. This is sometimes helpful to find excessive clone operations by a single user |
+| `json.grpc.request.glRepository`     | A repository in question. In the form of `project-<project_id>` eg: `project-214`  | In order to see how many clones/fetches were for a given repository. |
+| `json.grpc.request.glProjectPath`    | A repository in question. In the form of a project path eg: `my-org/coolproject`  | In order to see how many clones/fetches were for a given repository. |
+
+The following are log entry fields that give useful information about cpu and
+memory:
+
+| Log field to inspect     | What does it tell you?                                          |
+|--------------------------|-----------------------------------------------------------------|
+| `json.command.cpu_time_ms` | How much CPU time used by subprocesses this RPC spawned         |
+| `json.command.maxrss`      | How much memory was consumed from subprocesses this RPC spawned |
+
+Example log message:
+
+```json
+{
+    "command.count":2,
+    "command.cpu_time_ms":420,
+    "command.inblock":0,
+    "command.majflt":0,
+    "command.maxrss":3342152,
+    "command.minflt":24316,
+    "command.oublock":56,
+    "command.real_time_ms":626,
+    "command.spawn_token_fork_ms":4,
+    "command.spawn_token_wait_ms":0,
+    "command.system_time_ms":172,
+    "command.user_time_ms":248,
+    "component":"gitaly.StreamServerInterceptor",
+    "correlation_id":"20HCB3DAEPLV08UGNIYT9HJ4JW",
+    "environment":"gprd",
+    "feature_flags":"",
+    "fqdn":"file-99-stor-gprd.c.gitlab-production.internal",
+    "grpc.code":"OK",
+    "grpc.meta.auth_version":"v2",
+    "grpc.meta.client_name":"gitlab-workhorse",
+    "grpc.meta.deadline_type":"none",
+    "grpc.meta.method_operation":"mutator",
+    "grpc.meta.method_scope":"repository",
+    "grpc.meta.method_type":"bidi_stream",
+    "grpc.method":"PostReceivePack",
+    "grpc.request.fullMethod":"/gitaly.SmartHTTPService/PostReceivePack",
+    "grpc.request.glProjectPath":"r2414/revenir/development/machinelearning/protein-ddg",
+    "grpc.request.glRepository":"project-47506374",
+    "grpc.request.payload_bytes":911,
+    "grpc.request.repoPath":"@hashed/db/ab/dbabf83f57affedc9a001dc6c6f6b47bb431bd47d7254edd1daf24f0c38793a9.git",
+    "grpc.request.repoStorage":"nfs-file99",
+    "grpc.response.payload_bytes":54
+    "grpc.service":"gitaly.SmartHTTPService",
+    "grpc.start_time":"2023-10-16T20:40:08.836",
+    "grpc.time_ms":631.486,
+    "hostname":"file-99-stor-gprd",
+    "level":"info",
+    "msg":"finished streaming call with code OK",
+    "pid":1741362,
+    "remote_ip":"108.163.136.48",
+    "shard":"default",
+    "span.kind":"server",
+    "stage":"main",
+    "system":"grpc",
+    "tag":"gitaly",
+    "tier":"stor",
+    "time":"2023-10-16T20:40:09.467Z",
+    "trace.traceid":"AAB3QAeD8G+H9VNmzOi2CztMAcJv1+g4+l1cAgA=",
+    "type":"gitaly",
+    "user_id":"user-14857500",
+    "username":"ctx_ckottke",
+  }
+```
+
+### Read distribution
+
+The `gitaly_praefect_read_distribution` Prometheus metric is a
+[counter](https://prometheus.io/docs/concepts/metric_types/#counter) that
+indicates how many reads have gone to which Gitaly nodes. This metric has two
+vectors:
+
+| Metric Name                         | Vector           | What is it?                                                                                         |
+|-------------------------------------|------------------------------------------------------------------------------------------------------------------------|
+| `gitaly_praefect_read_distribution` | `virtual_storage`| The [virtual storage](../../../../administration/gitaly/praefect.md) name |
+| `gitaly_praefect_read_distribution` | `storage`        | The Gitaly storage name                                                                             |
+
+### Pack objects cache
+
+The [pack objects cache](../../../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
+can be observed through both logs as well as Prometheus metrics.
+
+| Log field name | Description |
+|:---|:---|
+| `pack_objects_cache.hit` | Indicates whether the current pack-objects cache was hit (`true` or `false`) |
+| `pack_objects_cache.key` | Cache key used for the pack-objects cache |
+| `pack_objects_cache.generated_bytes` | Size (in bytes) of the new cache being written |
+| `pack_objects_cache.served_bytes` | Size (in bytes) of the cache being served |
+| `pack_objects.compression_statistics` | Statistics regarding pack-objects generation |
+| `pack_objects.enumerate_objects_ms` | Total time (in ms) spent enumerating objects sent by clients |
+| `pack_objects.prepare_pack_ms` | Total time (in ms) spent preparing the packfile before sending it back to the client |
+| `pack_objects.write_pack_file_ms` | Total time (in ms) spent sending back the packfile to the client. Highly dependent on the client's internet connection |
+| `pack_objects.written_object_count` | Total number of objects Gitaly sends back to the client |
+
+Example log message:
+
+```json
+{
+"bytes":26186490,
+"correlation_id":"01F1MY8JXC3FZN14JBG1H42G9F",
+"grpc.meta.deadline_type":"none",
+"grpc.method":"PackObjectsHook",
+"grpc.request.fullMethod":"/gitaly.HookService/PackObjectsHook",
+"grpc.request.glProjectPath":"root/gitlab-workhorse",
+"grpc.request.glRepository":"project-2",
+"grpc.request.repoPath":"@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.git",
+"grpc.request.repoStorage":"default",
+"grpc.request.topLevelGroup":"@hashed",
+"grpc.service":"gitaly.HookService",
+"grpc.start_time":"2021-03-25T14:57:52.747Z",
+"level":"info",
+"msg":"finished unary call with code OK",
+"peer.address":"@",
+"pid":20961,
+"span.kind":"server",
+"system":"grpc",
+"time":"2021-03-25T14:57:53.543Z",
+"pack_objects.compression_statistics": "Total 145991 (delta 68), reused 6 (delta 2), pack-reused 145911",
+"pack_objects.enumerate_objects_ms": 170,
+"pack_objects.prepare_pack_ms": 7,
+"pack_objects.write_pack_file_ms": 786,
+"pack_objects.written_object_count": 145991,
+"pack_objects_cache.generated_bytes": 49533030,
+"pack_objects_cache.hit": "false",
+"pack_objects_cache.key": "123456789",
+"pack_objects_cache.served_bytes": 49533030,
+"peer.address": "127.0.0.1",
+"pid": 8813,
+}
+```
+
+| Prometheus metric name | Vector | Description |
+|:---|:---|
+| `gitaly_pack_objects_served_bytes_total` | | Size (in bytes) of the cache being served|
+| `gitaly_pack_objects_cache_lookups_total` | `result` | `hit` or `miss`,indicating whether or not a cache lookup resulted in a cache hit or miss |
diff --git a/doc/user/project/repository/monorepos/optimize_settings.md b/doc/user/project/repository/monorepos/optimize_settings.md
new file mode 100644
index 00000000000..144f46cd7d5
--- /dev/null
+++ b/doc/user/project/repository/monorepos/optimize_settings.md
@@ -0,0 +1,356 @@
+---
+stage: Systems
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Managing monorepos
+
+Monorepos have become a regular part of development team workflows. While they have many advantages, monorepos can present performance challenges
+when using them in GitLab. Therefore, you should know:
+
+- What repository characteristics can impact performance.
+- Some tools and steps to optimize monorepos.
+
+## Impact on performance
+
+Because GitLab is a Git-based system, it is subject to similar performance
+constraints as Git when it comes to large repositories that are gigabytes in
+size.
+
+Monorepos can be large for [many reasons](https://about.gitlab.com/blog/2022/09/06/speed-up-your-monorepo-workflow-in-git/#characteristics-of-monorepos).
+
+Large repositories pose a performance risk performance when used in GitLab, especially if a large monorepo receives many clones or pushes a day, which is common for them.
+
+Git itself has performance limitations when it comes to handling
+monorepos.
+
+Monorepos can also impact notably on hardware, in some cases hitting limitations such as vertical scaling and network or disk bandwidth limits.
+
+[Gitaly](https://gitlab.com/gitlab-org/gitaly) is our Git storage service built
+on top of [Git](https://git-scm.com/). This means that any limitations of
+Git are experienced in Gitaly, and in turn by end users of GitLab.
+
+## Optimize GitLab settings
+
+You should use as many of the following strategies as possible to minimize
+fetches on the Gitaly server.
+
+### Rationale
+
+The most resource intensive operation in Git is the
+[`git-pack-objects`](https://git-scm.com/docs/git-pack-objects) process. It is
+responsible for figuring out all of the commit history and files to send back to
+the client.
+
+The larger the repository, the more commits, files, branches, and tags that a
+repository has and the more expensive this operation is. Both memory and CPU
+are heavily utilized during this operation.
+
+Most `git clone` or `git fetch` traffic (which results in starting a `git-pack-objects` process on the server) often come from automated
+continuous integration systems such as GitLab CI/CD or other CI/CD systems.
+If there is a high amount of such traffic, hitting a Gitaly server with many
+clones for a large repository is likely to put the server under significant
+strain.
+
+### Gitaly pack-objects cache
+
+Turn on the [Gitaly pack-objects cache](../../../../administration/gitaly/configure_gitaly.md#pack-objects-cache),
+which reduces the work that the server has to do for clones and fetches.
+
+#### Rationale
+
+The [pack-objects cache](../../../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
+caches the data that the `git-pack-objects` process produces. This response
+is sent back to the Git client initiating the clone or fetch. If several
+fetches are requesting the same set of refs, Git on the Gitaly server doesn't have
+to re-generate the response data with each clone or fetch call, but instead serves
+that data from an in-memory cache that Gitaly maintains.
+
+This can help immensely in the presence of a high rate of clones for a single
+repository.
+
+For more information, see [Pack-objects cache](../../../../administration/gitaly/configure_gitaly.md#pack-objects-cache).
+
+### Reduce concurrent clones in CI/CD
+
+CI/CD loads tend to be concurrent because pipelines are scheduled during set times.
+As a result, the Git requests against the repositories can spike notably during
+these times and lead to reduced performance for both CI/CD and users alike.
+
+Reduce CI/CD pipeline concurrency by staggering them to run at different times.
+For example, a set running at one time and another set running several minutes
+later.
+
+### Shallow cloning
+
+In your CI/CD systems, set the
+[`--depth`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt)
+option in the `git clone` or `git fetch` call.
+
+GitLab and GitLab Runner perform a [shallow clone](../../../../ci/pipelines/settings.md#limit-the-number-of-changes-fetched-during-clone)
+by default.
+
+If possible, set the clone depth with a small number like 10. Shallow clones make Git request only
+the latest set of changes for a given branch, up to desired number of commits.
+
+This significantly speeds up fetching of changes from Git repositories,
+especially if the repository has a very long backlog consisting of a number
+of big files because we effectively reduce amount of data transfer.
+
+The following GitLab CI/CD pipeline configuration example sets the `GIT_DEPTH`.
+
+```yaml
+variables:
+  GIT_DEPTH: 10
+
+test:
+  script:
+    - ls -al
+```
+
+### Git strategy
+
+Use `git fetch` instead of `git clone` on CI/CD systems if it's possible to keep
+a working copy of the repository.
+
+By default, GitLab is configured to use the [`fetch` Git strategy](../../../../ci/runners/configure_runners.md#git-strategy),
+which is recommended for large repositories.
+
+#### Rationale
+
+`git clone` gets the entire repository from scratch, whereas `git fetch` only
+asks the server for references that do not already exist in the repository.
+Naturally, `git fetch` causes the server to do less work. `git-pack-objects`
+doesn't have to go through all branches and tags and roll everything up into a
+response that gets sent over. Instead, it only has to worry about a subset of
+references to pack up. This strategy also reduces the amount of data to transfer.
+
+### Git clone path
+
+[`GIT_CLONE_PATH`](../../../../ci/runners/configure_runners.md#custom-build-directories) allows you to
+control where you clone your repositories. This can have implications if you
+heavily use big repositories with a fork-based workflow.
+
+A fork, from the perspective of GitLab Runner, is stored as a separate repository
+with a separate worktree. That means that GitLab Runner cannot optimize the usage
+of worktrees and you might have to instruct GitLab Runner to use that.
+
+In such cases, ideally you want to make the GitLab Runner executor be used only
+for the given project and not shared across different projects to make this
+process more efficient.
+
+The [`GIT_CLONE_PATH`](../../../../ci/runners/configure_runners.md#custom-build-directories) must be
+in the directory set in `$CI_BUILDS_DIR`. You can't pick any path from disk.
+
+### Git clean flags
+
+[`GIT_CLEAN_FLAGS`](../../../../ci/runners/configure_runners.md#git-clean-flags) allows you to control
+whether or not you require the `git clean` command to be executed for each CI/CD
+job. By default, GitLab ensures that:
+
+- You have your worktree on the given SHA.
+- Your repository is clean.
+
+[`GIT_CLEAN_FLAGS`](../../../../ci/runners/configure_runners.md#git-clean-flags) is disabled when set
+to `none`. On very big repositories, this might be desired because `git
+clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
+-e .build/` (for example) allows you to control and disable removal of some
+directories in the worktree between subsequent runs, which can speed-up
+the incremental builds. This has the biggest effect if you re-use existing
+machines and have an existing worktree that you can re-use for builds.
+
+For exact parameters accepted by
+[`GIT_CLEAN_FLAGS`](../../../../ci/runners/configure_runners.md#git-clean-flags), see the documentation
+for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
+are dependent on the Git version.
+
+### Git fetch extra flags
+
+[`GIT_FETCH_EXTRA_FLAGS`](../../../../ci/runners/configure_runners.md#git-fetch-extra-flags) allows you
+to modify `git fetch` behavior by passing extra flags.
+
+For example, if your project contains a large number of tags that your CI/CD jobs don't rely on,
+you could add [`--no-tags`](https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---no-tags)
+to the extra flags to make your fetches faster and more compact.
+
+Also in the case where you repository does _not_ contain a lot of
+tags, `--no-tags` can [make a big difference in some cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
+If your CI/CD builds do not depend on Git tags, setting `--no-tags` is worth trying.
+
+For more information, see the [`GIT_FETCH_EXTRA_FLAGS` documentation](../../../../ci/runners/configure_runners.md#git-fetch-extra-flags).
+
+### Configure Gitaly negotiation timeouts
+
+You might experience a `fatal: the remote end hung up unexpectedly` error when attempting to fetch or archive:
+
+- Large repositories.
+- Many repositories in parallel.
+- The same large repository in parallel.
+
+You can attempt to mitigate this issue by increasing the default negotiation timeout values. For more information, see
+[Configure negotiation timeouts](../../../../administration/gitaly/configure_gitaly.md#configure-negotiation-timeouts).
+
+## Optimize your repository
+
+Another avenue to keeping GitLab scalable with your monorepo is to optimize the
+repository itself.
+
+### Profiling repositories
+
+Large repositories generally experience performance issues in Git. Knowing why
+your repository is large can help you develop mitigation strategies to avoid
+performance problems.
+
+You can use [`git-sizer`](https://github.com/github/git-sizer) to get a snapshot
+of repository characteristics and discover problem aspects of your monorepo.
+
+For example:
+
+```shell
+Processing blobs: 1652370
+Processing trees: 3396199
+Processing commits: 722647
+Matching commits to trees: 722647
+Processing annotated tags: 534
+Processing references: 539
+| Name                         | Value     | Level of concern               |
+| ---------------------------- | --------- | ------------------------------ |
+| Overall repository size      |           |                                |
+| * Commits                    |           |                                |
+|   * Count                    |   723 k   | *                              |
+|   * Total size               |   525 MiB | **                             |
+| * Trees                      |           |                                |
+|   * Count                    |  3.40 M   | **                             |
+|   * Total size               |  9.00 GiB | ****                           |
+|   * Total tree entries       |   264 M   | *****                          |
+| * Blobs                      |           |                                |
+|   * Count                    |  1.65 M   | *                              |
+|   * Total size               |  55.8 GiB | *****                          |
+| * Annotated tags             |           |                                |
+|   * Count                    |   534     |                                |
+| * References                 |           |                                |
+|   * Count                    |   539     |                                |
+|                              |           |                                |
+| Biggest objects              |           |                                |
+| * Commits                    |           |                                |
+|   * Maximum size         [1] |  72.7 KiB | *                              |
+|   * Maximum parents      [2] |    66     | ******                         |
+| * Trees                      |           |                                |
+|   * Maximum entries      [3] |  1.68 k   | *                              |
+| * Blobs                      |           |                                |
+|   * Maximum size         [4] |  13.5 MiB | *                              |
+|                              |           |                                |
+| History structure            |           |                                |
+| * Maximum history depth      |   136 k   |                                |
+| * Maximum tag depth      [5] |     1     |                                |
+|                              |           |                                |
+| Biggest checkouts            |           |                                |
+| * Number of directories  [6] |  4.38 k   | **                             |
+| * Maximum path depth     [7] |    13     | *                              |
+| * Maximum path length    [8] |   134 B   | *                              |
+| * Number of files        [9] |  62.3 k   | *                              |
+| * Total size of files    [9] |   747 MiB |                                |
+| * Number of symlinks    [10] |    40     |                                |
+| * Number of submodules       |     0     |                                |
+```
+
+In this example, a few items are raised with a high level of concern. See the
+following sections for information on solving:
+
+- A large number of references.
+- Large blobs.
+
+### Large number of references
+
+[References in Git](https://git-scm.com/book/en/v2/Git-Internals-Git-References)
+are branch and tag names that point to a particular commit. You can use the `git
+for-each-ref` command to list all references present in a repository. A large
+number of references in a repository can have detrimental impact on the command's
+performance. To understand why, we need to understand how Git stores references
+and uses them.
+
+In general, Git stores all references as loose files in the `.git/refs` folder of
+the repository. As the number of references grows, the seek time to find a
+particular reference in the folder also increases. Therefore, every time Git has
+to parse a reference, there is an increased latency due to the added seek time
+of the file system.
+
+To resolve this issue, Git uses [pack-refs](https://git-scm.com/docs/git-pack-refs). In short, instead of storing each
+reference in a single file, Git creates a single `.git/packed-refs` file that
+contains all the references for that repository. This file reduces storage space
+while also increasing performance because seeking within a single file is faster
+than seeking a file within a directory. However, creating and updating new references
+is still done through loose files and are not added to the `packed-refs` file. To
+recreate the `packed-refs` file, run `git pack-refs`.
+
+Gitaly runs `git pack-refs` during [housekeeping](../../../../administration/housekeeping.md#heuristical-housekeeping)
+to move loose references into `packed-refs` files. While this is very beneficial
+for most repositories, write-heavy repositories still have the problem that:
+
+- Creating or updating references creates new loose files.
+- Deleting references involves modifying the existing `packed-refs` file
+  altogether to remove the existing reference.
+
+These problems still cause the same performance issues.
+
+In addition, fetches and clones from repositories includes the transfer
+of missing objects from the server to the client. When there are numerous
+references, Git iterates over all references and walks the internal graph
+structure for each reference to find the missing objects to transfer to
+the client. Iteration and walking are CPU-intensive operations that increase
+the latency of these commands.
+
+In repositories with a lot of activity, this often causes a domino effect because
+every operation is slower and each operation stalls subsequent operations.
+
+#### Mitigation strategies
+
+To mitigate the effects of a large number of references in a monorepo:
+
+- Create an automated process for cleaning up old branches.
+- If certain references don't need to be visible to the client, hide them using the
+  [`transfer.hideRefs`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-transferhideRefs)
+  configuration setting. Because Gitaly ignores any on-server Git configuration, you must change the Gitaly configuration
+  itself in `/etc/gitlab/gitlab.rb`:
+
+  ```ruby
+  gitaly['configuration'] = {
+    # ...
+    git: {
+      # ...
+      config: [
+        # ...
+        { key: "transfer.hideRefs", value: "refs/namespace_to_hide" },
+      ],
+    },
+  }
+  ```
+
+In Git 2.42.0 and later, different Git operations can skip over hidden references
+when doing an object graph walk.
+
+### Large blobs
+
+The presence of large files (called blobs in Git), can be problematic for Git
+because it does not handle large binary files efficiently. If there are blobs over
+10 MB or instance in the `git-sizer` output, this probably means there is binary
+data in your repository.
+
+#### Use LFS for large blobs
+
+Store binary or blob files (for example, packages, audio, video, or graphics)
+as Large File Storage (LFS) objects. With LFS, the objects are stored externally, such as in Object
+Storage, which reduces the number and size of objects in the repository. Storing
+objects in external Object Storage can improve performance.
+
+For more information, refer to the [Git LFS documentation](../../../../topics/git/lfs/index.md).
+
+### Reference architectures
+
+Large repositories tend to be found in larger organisations with many users. The
+GitLab Quality Engineering and Support teams provide several [reference architectures](../../../../administration/reference_architectures/index.md) that
+are the recommended way to deploy GitLab at scale.
+
+In these types of setups, the GitLab environment used should match a reference
+architecture to improve performance.