Preserve Approvals in Stacked Merge Requests

Problem to Solve

When working with stacked/chained merge requests, merging one MR in the stack causes all related MRs to lose their approvals, even though the actual code changes have already been reviewed and approved. This forces teams to re-approve unchanged code, creating unnecessary friction in the review process.

Expected Use Case

Development teams using stacked MRs to break large features into smaller, reviewable chunks need to:

  1. Get approval on MR1 (branch1 → main)
  2. Get approval on MR2 (branch2 → branch1)
  3. Merge MR1, which automatically retargets MR2 to main
  4. Have MR2 retain its approval status since the code diff remains unchanged

Current Behavior:

  • When MR1 merges, MR2 is retargeted from branch1 → main
  • MR2 loses all approvals despite containing the same code changes
  • Reviewers must re-approve already-reviewed code
  • This happens even though the diff in MR2 is identical before and after retargeting

Proposal

Implement "smart approval preservation" for stacked MRs:

  1. When an MR's target branch changes due to a merge in the stack, compare the MR's diff before and after the retargeting
  2. If the diff remains unchanged (same files, same changes), preserve existing approval and only reset approvals when actual code changes occur in the MR
  3. Merges from an approved MR (branch_2) into another approved MR (branch_1) should retain approvals even though the diff between branch_1 MR and main will change.
Edited by Ross Cain