Provide web UI to tidy-up commits of the MR before merging it

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

• Close this issue

Problem to solve

If we use many GitLab features in our project (e.g., CI with tests and review apps) a reviewer of the MR does not even have to run anything locally, nor do they have to run any git operations locally to do the merge. Or at least this would be ideal. But currently, if reviewer wants to merge a finished MR, there is no way to tidy up the MR before merging it. You can squash everything into one commit, or you can merge as-is. But you cannot tidy few commits by combining them with other commits and things like that. Simply, you cannot do all operations described here and here.

Intended users

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/

• Sasha (Software Developer)

User experience goal

Goal is that the user does not have to leave GitLab Web UI to do the whole merge of the merge request.

Proposal

I think current "Commits" tab of the MR is heavily underused during the whole MR process. As such I think it is ideal place to add UI to manage commits of UI. Probably more or less replicating the interactive git rebase UI. The difference is that everything can be done at once:

• For every commit, one should be able to select:
  • pick (default)
  • reword
  • squash
  • fixup
  • drop
• There should be probably a way to bulk apply those selections to a bunch of commits.
• For "reword" option, when selected, a text area could be shown immediately under the commit for one to edit the commit message.
• After do this selection, there can be a button in that tab called "Rebase" or "Tidy" or "Apply" to run those.

This could allow big changes but also very small change like just editing commit message of a single commit.

Further details

This should behave exactly the same as it would be done locally, only through web interface. It would rebase and force-push to that branch a rebased history, updating web UI afterwards.

Permissions and Security

Permissions should match those regularly used to add commits and force push to the MR's branch.