<!--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=227319) </details> <!--IssueSummary end--> # how to reproduce ## configure project: - [x] enable approvals in project - [x] enable reset approvals on push: https://gitlab.delfi.net/help/user/project/merge_requests/merge_request_approvals#resetting-approvals-on-push # typical flow - developer makes commit - reviewer requests changes - developer makes `fixup!` commit - reviewer gives approval but merge should not be performed before the fixup commits are flattened. doing normal rebase from UI does not reset approval, but doing `git rebase -i --autosquash` from commandline resets the approvals. # the enhancement the enhancement would be to make the autosquash rebase from the UI, or gitlab able to understand that user made a push that only squashed commits, did not perform any other changes. maybe, if it's easier to implement, is to require base branch to be exactly the same before the push after autosquash: 1. rebase against base branch. push 2. rebase against target branch from the ui 2. approval is preserved extra considerations: - account only diffs, or commit message, authors, any other metadata?