<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=463356) </details> <!--IssueSummary end--> ## Background With the implementation of `auto-merge` we [made a decision](https://gitlab.com/gitlab-org/gitlab/-/issues/461198#note_1914875062) to reset the `auto-merge` status if the target branch changes. However, the [long term vision](https://gitlab.com/gitlab-org/gitlab/-/issues/462286) for `auto-merge` is that we don't want it to be a user action and more something that "just happens". ## Proposal When a merge request is re-targeted through our automatic retargeting, we should retain the `auto-merge` status. This means that users won't need to come back and hit `auto-merge`. ### Concerns If we leave the `auto-merge` set, then a merge request could merge... which wasn't the intent when the `auto-merge` was set. Kai's answer to this is that merge checks should be the gate which prevents something from being merged, not the fact that someone does or does not hit the `auto-merge` button. For example, if a branch is retargeted, we reset the approvals when that happens. That means that if the approvals are the gate, and so it doesn't matter if `auto-merge` is set.