@@ -626,3 +626,12 @@ Set the limit to `0` to allow any file size.
### Package versions returned
When asking for versions of a given NuGet package name, the GitLab Package Registry returns a maximum of 300 versions.
## Automatically retargeting merge requests
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9.
Maximum of 4 merge requests point to the currently being merged
will be automatically retargeted upon merge.
More information can be found in the [Automatically retargeting merge requests](../user/project/merge_requests/getting_started.md#automatically-retargeting-merge-requests).
> - [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 disabled on GitLab.com.
> - 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)**
It is common to have a number of merge requests in a chain,
when one depends on another. For example:
- Merge Request A: merge `feature-A` into `master`
- Merge Request B: merge `feature-B` into `feature-A`
We can distinguish two workflows:
- the MR A is merged into `master` first, and then MR B is retargeted onto `master`
- the MR B is merged into `feature-A` branch, and then MR A is merged into `master`
Upon merge of `MR A` does automatically retarget the `MR B` onto `master`.
This relieves user from having to perform this operation manually.
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
- When working locally in your branch, add multiple commits and only push when