... | ... | @@ -77,15 +77,15 @@ Finally, the *Changes* tab shows the patch itself. This view may be restricted t |
|
|
## Merging your merge request
|
|
|
|
|
|
We use @marge-bot to automatically rebase and merge branches to `master`.
|
|
|
After your merge request has been reviewed and approved you can request that it be added to the merge queue by @-mentioning @reviewers. Your MR should be added to the merge queue within a day or two.
|
|
|
After your merge request has been reviewed and approved, you can request that it be added to the merge queue by @-mentioning @reviewers. Your MR should be added to the merge queue within a day or two, assuming it passes CI and the commit history is in order (individually buildable commits with informative commit messages).
|
|
|
|
|
|
As long as your MR satisfies the following, GitLab will batch your MR with other MRs and attempt to merge into `master`:
|
|
|
|
|
|
* Approved by a GHC developer
|
|
|
* Passing CI
|
|
|
* Is assigned to @marge-bot
|
|
|
* Passes CI
|
|
|
* Has no merge conflicts with `master `(see rebasing below)
|
|
|
|
|
|
Each batch is an MR and must pass CI, so you can expect GitLab to merge two or three batches per day.
|
|
|
Each batch is an MR of its own, which must itself pass CI. You can expect GitLab to merge two or three batches per day.
|
|
|
|
|
|
### Rebasing
|
|
|
|
... | ... | |