Commit 296cdaf8 authored by Amy Qualls's avatar Amy Qualls Committed by Kamil Trzciński

Add variants of 'retarget' to spelling dictionary

With a new feature, we need to allow variants of the word 'retarget'
in our spelling exceptions dictionary.
parent a0860573
...@@ -488,6 +488,10 @@ resync ...@@ -488,6 +488,10 @@ resync
resynced resynced
resyncing resyncing
resyncs resyncs
retarget
retargeted
retargeting
retargets
reusability reusability
reverified reverified
reverifies reverifies
......
...@@ -627,11 +627,10 @@ Set the limit to `0` to allow any file size. ...@@ -627,11 +627,10 @@ Set the limit to `0` to allow any file size.
When asking for versions of a given NuGet package name, the GitLab Package Registry returns a maximum of 300 versions. When asking for versions of a given NuGet package name, the GitLab Package Registry returns a maximum of 300 versions.
## Automatically retargeting merge requests ## Branch retargeting on merge **(FREE SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9.
Maximum of 4 merge requests point to the currently being merged If a branch is merged while open merge requests still point to it, GitLab can
will be automatically retargeted upon merge. retarget merge requests pointing to the now-merged branch. To learn more, read
[Branch retargeting on merge](../user/project/merge_requests/getting_started.md#branch-retargeting-on-merge).
More information can be found in the [Automatically retargeting merge requests](../user/project/merge_requests/getting_started.md#automatically-retargeting-merge-requests).
...@@ -194,32 +194,32 @@ is set for deletion, the merge request widget displays the ...@@ -194,32 +194,32 @@ is set for deletion, the merge request widget displays the
![Delete source branch status](img/remove_source_branch_status.png) ![Delete source branch status](img/remove_source_branch_status.png)
### Automatically retargeting merge requests ### Branch retargeting on merge **(FREE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9.
> - It's [deployed behind a feature flag](../../feature_flags.md), disabled by default. > - It's [deployed behind a feature flag](../../feature_flags.md), disabled by default.
> - It's disabled on GitLab.com. > - It's disabled on GitLab.com.
> - It's not recommended for production use. > - It's not recommended for production use.
> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-automatically-retargeting-merge-requests). **(FREE SELF)** > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-branch-retargeting-on-merge).
It is common to have a number of merge requests in a chain, In specific circumstances, GitLab can retarget the destination branch of
when one depends on another. For example: open merge request, if the destination branch merges while the merge request is
open. Merge requests are often chained in this manner, with one merge request
depending on another:
- Merge Request A: merge `feature-A` into `master` - **Merge request 1**: merge `feature-alpha` into `master`.
- Merge Request B: merge `feature-B` into `feature-A` - **Merge Request 2**: merge `feature-beta` into `feature-alpha`.
We can distinguish two workflows: These merge requests are usually handled in one of these ways:
- the MR A is merged into `master` first, and then MR B is retargeted onto `master` - Merge request 1 is merged into `master` first. Merge request 2 is then
- the MR B is merged into `feature-A` branch, and then MR A is merged into `master` retargeted to `master`.
- Merge request 2 is merged into `feature-alpha`. The updated merge request 1, which
now contains the contents of `feature-alpha` and `feature-beta`, is merged into `master`.
Upon merge of `MR A` does automatically retarget the `MR B` onto `master`. GitLab retargets up to four merge requests when their target branch is merged into
This relieves user from having to perform this operation manually. `master`, so you don't need to perform this operation manually. Merge requests from
forks are not retargeted.
This feature works only in following cases:
- The MR A needs to be in a main project (forks are not supported), as we, GitLab, cannot change the target project of MR B
- Only 4 MR's of type B are retargeted automatically this way
## Recommendations and best practices for Merge Requests ## Recommendations and best practices for Merge Requests
...@@ -258,7 +258,7 @@ Feature.disable(:reviewer_approval_rules) ...@@ -258,7 +258,7 @@ Feature.disable(:reviewer_approval_rules)
Feature.disable(:reviewer_approval_rules, Project.find(<project id>)) Feature.disable(:reviewer_approval_rules, Project.find(<project id>))
``` ```
### Enable or disable Automatically retargeting merge requests **(FREE SELF)** ### Enable or disable branch retargeting on merge **(FREE SELF)**
Automatically retargeting merge requests is under development but ready for production use. Automatically retargeting merge requests is under development but ready for production use.
It is deployed behind a feature flag that is **enabled by default**. It is deployed behind a feature flag that is **enabled by default**.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment