## Summary Currently, rebasing an MR programmatically requires posting a `/rebase` quick action as a note. This works but has limitations for API consumers and AI agents: - It's a side effect of note processing, not a dedicated API - The operation is asynchronous with no direct feedback on completion/success - No way to get the new commit SHA without polling ## Proposal Add a dedicated GraphQL mutation for rebasing merge requests, similar to how we have `mergeRequestAccept` for merging. ```graphql mutation mergeRequestRebase($projectPath: ID!, $iid: String!) { mergeRequestRebase(input: { projectPath: $projectPath, iid: $iid }) { mergeRequest { iid diffHeadSha rebaseInProgress } errors } } ``` ## Benefits - **Proper API semantics** - Explicit mutation rather than note side effect - **Better error handling** - Direct response with errors array - **Clearer feedback** - Return the new SHA and rebase status - **Improved tooling support** - Easier for CI/CD tools, scripts, and AI agents to integrate ## Context This came up in discussion on https://gitlab.com/gitlab-org/gitlab/-/merge_requests/220216#note_3060871733 regarding AI agent guidelines. The `/rebase` quick action works but a proper mutation would be preferable for programmatic use. ## Related - REST API already has `PUT /projects/:id/merge_requests/:merge_request_iid/rebase` - This would add GraphQL parity