Allow approvals to persist after rebase when "Prevent approvals by users who add commits" is enabled

Problem

Currently, when the "Prevent approvals by users who add commits" setting is enabled, users lose their ability to approve a merge request after performing a rebase operation, even though rebasing doesn't introduce new functional changes to the code.

This creates friction in workflows where:

  • Reviewers approve an MR
  • The author needs to rebase to resolve conflicts or update the target branch
  • Additional reviewers must approve, even though no functional changes were made

Proposal

GitLab should distinguish between different types of commit operations:

Primary Solution

Make the approval system "rebase-aware" by:

  • Preserving approvals when commits are added via rebase operations
  • Only revoking approvals when users make actual functional commits (new code changes)

Alternative Solution

Add a more granular setting option:

  • Current: "Prevent approvals by users who add commits" (all commits)
  • New: "Prevent approvals by commit authors" (only original authorship, not rebase operations)

Expected Behavior

Scenario 1: Rebase operation

  1. User A approves MR
  2. User A rebases the MR to resolve conflicts or update target branch
  3. User A retains approval ability ✅

Scenario 2: New functional commit

  1. User A approves MR
  2. User A adds a new commit with code changes
  3. User A loses approval ability ❌ (current behavior maintained)

Benefits

  • Reduces approval friction in rebase-heavy workflows
  • Maintains security by still preventing approvals from users who add functional changes
  • Improves developer experience without compromising code review integrity
  • Aligns with the intent of the original setting (preventing self-approval of new code)

Implementation Considerations

  • Might require tracking the nature of commit operations in the MR timeline
  • Should maintain backward compatibility with existing approval workflows

Related

This would improve workflows commonly used in:

  • Projects with frequent target branch updates
  • Teams using rebase-based merge strategies
  • Environments with strict approval requirements
Edited by 🤖 GitLab Bot 🤖