Follow-up from "Verify fast-forward merge advances the target branch"

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

The following discussions from !239586 (merged) should be addressed:

  • @hfyngvason started a discussion:

    For a follow-up: I think we should also harden app/services/merge_requests/create_ref_service.rb against rebase collapse. That would have prevented the auto-rebase variant of this issue, and address the same issue for merge trains.

  • @hfyngvason started a discussion:

    Nit (not blocking): CreateRefService also accepts a SHA for first_parent_ref, so we could actually resolve this once and make the target_sha: optimistic lock a mandatory argument to fast_forward!. I wouldn't bother with it now, but maybe after cleaning up the flag.

  • @hfyngvason started a discussion:

    Nit (not blocking): Since this is a fast-forward, commit_sha == prior_target_sha is equivalent to checking src_sha == prior_target_sha before attempting #ff_merge.

Edited by 🤖 GitLab Bot 🤖