Marge breaks in the presence of forks

[bgamari]

The were hoping to use Marge in the GHC project to implement batched merges until proper support appears in GitLab. Unfortunately, Marge expects to be able to push to the source branch which is not easily possible in a public project like GHC where merge requests often originate from forks. It appears that the only way around this is currently to manually add the Marge bot account as a maintainer for all users' forks. Naturally, this seems quite intrusive.

I believe this would be easily avoided if Marge used GitLab's native rebase API (#157).

[jcpetruzza]

The problem with using GitLab's api for rebasing is, I think, that you then can't have Marge adding trailers to the commits ("Tested-by", "Part-of", etc). But if that is a feature you weren't planning to use, then something like a --rebase-on-gitlab flag could probably be added which (hopefully) shouldn't be a terribly intrusive change: Marge would still work on the local repo, and do a rebase there, but at the point of pushing the changes back to the merge request branch, she would instead request a rebase, wait for the result, and if the operation succeeds, she needs to check that the new top-commit of the MR matches the one she has on her local branch (i.e., the one that she would have otherwise pushed).

Do you think something like that would work in your setting?

[bgamari]

Indeed that is more-or-less what I did (albeit in a terrible, awful, no-good hacky way). See bgamari@11a908b. I may try to clean this up to submit upstream once things have stabilized on our end.

Thanks for your help!

[jcpetruzza]

@bgamari I gave this a shot in the PR above; let me know if works for you?

[JaimeLennox]

I think this can be closed now. There is support for rebasing via the GitLab API.