Better rebase merge workflow
Description
When a contributor submits a merge request from their personal clone, I as a project admin want to review and accept the request. Our project (mailman/mailman) uses fast-forward merges which should give us the option of rebasing through the u/i but never does. Rebasing is almost always required because as soon as we land a branch, all other merge requests will no longer be fast-forward merge-able. This requires me to do one of two things, both of which are productivity killers.
-
Ask the submitter to rebase their branch. This blocks us on actions from the submitter, which may take a long time or never happen for certain drive-by contributors. It's also quite inconvenient for them because if we land anything else between the time they rebase and we get back to reviewing their branch, then we'll just have to ask them to rebase again.
-
Fetch the branch and merge manually. Besides being a lot more work for us, this also means that we generally won't run CI on the locally rebased branch. What I've done in the past is push the rebased branch to a project branch, closed the original MR and opened a new one, but that's not great for several reasons because at that point, the original author isn't really involved in the review.
Proposal
Perhaps other solutions can be thought of, but one possibility is to rebase into a project owned branch through the u/i and automatically open a new MR linking to the original MR. Then, we'd continue to review on the original MR and any commits pushed there would be automatically rebased back into our project-owned MR.