+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Current merge rules are too inconvenient (/thread-2252.html)
Current merge rules are too inconvenient - LogicParrot - 12-13-2015
Currently, a single accepted merge blocks out all other PRs until their owners either rebase or merge "master" into their branch. This slows things down a lot. e.g. this
I think fixing this is extra urgent. It's significantly bottlenecking merges and a queue is building up.
This is making simple operations really hard. For instance, @Gargaj has 5 open PRs. He'll have to keep rebasing them after each merge in order for me to merge his next PR. That's at least 5 rebases.
RE: Current merge rules are too inconvenient - bearbin - 12-13-2015
Yes. This got disabled a while ago, how come it got re-enabled?
RE: Current merge rules are too inconvenient - worktycho - 12-13-2015
Because we need to require status checks. Protected branches shouldn't be blocking merges from my understanding of githubs docs.
Looking closer, it looks like if you enable required status checks, it blocks if the branch is not up to date with master. So you can't have the required status checks feature, and the ability to merge out of date PR's.
RE: Current merge rules are too inconvenient - LogicParrot - 12-13-2015
Quote:Because we need to require status checks.Can't we just ask people not to commit directly into `master` and not to merge before CI finishes? Do "status checks" provide any other features we use?
RE: Current merge rules are too inconvenient - worktycho - 12-14-2015
The don't force push master setting is separate, so we can keep that.
I'm going to try disabling this for a couple of weeks, and see what happens.
RE: Current merge rules are too inconvenient - xoft - 12-14-2015
We've had some trigger-happy people who would merge even before the CI completed, let alone some review from the others. I hope those are now educated enough
RE: Current merge rules are too inconvenient - LogicParrot - 12-17-2015
1. Blocking merges whose CI did not succeed / has not finished
2. Blocking merges whenever master is ahead of them by one or more commits
These sound like two seperate options to me. Are they interwined in Github for some reason?