Remove generated_ref_commits_for_automatic_rebase feature flag

Marc Shawrequested to merge
627604-remove-generated-ref-commits-for-automatic-rebase-ff into master

What does this MR do and why?

Removes the feature flag generated_ref_commits_for_automatic_rebase, which has been at 100 percent on GitLab.com since 2026-09-10 with no issues reported. The flag gated recording generated ref commits on automatic rebase before merge so rebased commits keep their MR association. Behaviour after removal matches the flag-on path already running in production.

Detailed context for AI agents

The flag generated_ref_commits_for_automatic_rebase (type gitlab_com_derisk, milestone 19.4, default_enabled: false) gated writing to the p_generated_ref_commits table when a merge request is merged with automatic rebase before merge, so rebased commits keep their merge request association on the target branch. Previously only merge trains wrote to this table.

Introduced in !253468 (merged). Feature issue: #627601 (closed). Rollout issue: #627604 (closed). Original request for help: https://gitlab.com/gitlab-com/request-for-help/-/work_items/5340.

Rollout history: enabled on staging 2026-09-10, project-scoped production test passed the same day, then 15 percent and 100 percent on GitLab.com, all on 2026-09-10. No issues reported since.

Changes (23 deleted lines across 4 files):

  • Deleted config/feature_flags/gitlab_com_derisk/generated_ref_commits_for_automatic_rebase.yml.
  • app/services/merge_requests/create_ref_service.rb: should_store_generated_ref_commits? now returns rebase_performed? directly, removing the Feature.enabled? guard. The EE override in ee/app/services/ee/merge_requests/create_ref_service.rb, which widens this for merge trains, is unchanged.
  • app/services/merge_requests/merge_strategies/from_source_branch.rb: cleanup_generated_ref_commits now always deletes the rows for the merge request when a fast-forward fails to advance the target branch, removing the Feature.enabled? guard.
  • spec/services/merge_requests/create_ref_service_spec.rb: removed the "when generated_ref_commits_for_automatic_rebase is disabled" context.

Known follow-ups tracked elsewhere and unchanged by this MR:

  • Rows written before a fast-forward attempt can be left behind on merge failure outside the cleanup path: #571785.
  • upsert_all does not deduplicate repeated merge attempts.

Verification: specs pass locally (57 examples, 0 failures) for spec/services/merge_requests/create_ref_service_spec.rb, spec/services/merge_requests/merge_strategies/from_source_branch_spec.rb, and ee/spec/services/ee/merge_requests/create_ref_service_spec.rb.

After this MR merges, the flag itself also needs deleting via chatops: /chatops gitlab run feature delete generated_ref_commits_for_automatic_rebase --dev --pre --staging --staging-ref --production.

References

Screenshots or screen recordings

Not applicable, backend flag removal with no UI change.

How to set up and validate locally

  1. On a project with merge method fast-forward or semi-linear and "automatic rebase before merge" enabled, create a merge request whose source branch is behind the target branch.
  2. Merge the merge request via the UI.
  3. In a rails console, confirm MergeRequests::GeneratedRefCommit.where(merge_request_iid: mr.iid, project_id: mr.project_id).count is greater than zero.
  4. Visit a rebased commit on the target branch and confirm it shows the merge request link.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports