## Problem to Solve Currently merge requests have a binary setting that [`removes all approvals when commits are added to the source branch`](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#remove-all-approvals-when-commits-are-added-to-the-source-branch). When this setting is enabled, trivial changes such as rebasing, updates to the target branch or others that the approvals are reset. Resetting the approvals forces authors to get approvals again, even when functionally nothing has changed in the proposed code change. ### Additional Details Conditions which reset approvals: 1. merging main to feature branch (`git merge main`) - https://gitlab.com/phikai/author-approval-test/-/merge_requests/2 1. `git rebase main` with a then pull (merge) and then push - https://gitlab.com/phikai/author-approval-test/-/merge_requests/3 1. `git rebase main` with a force push and no pull - https://gitlab.com/phikai/author-approval-test/-/merge_requests/4 ## Proposal GitLab should loosen the conditions on approval resets to support developers being able to keep their work updated and ready for merge, without requiring re-approval. ### Additional Details We should work to achieve this without introducing new settings as we change the restrictions here. Changes should become the new defaults and we can work to expand fine grained permission/control if required later.