On May 28, 2018, at 13:19, Nathaniel Smith email@example.com wrote:
Isn't that what happens if someone enables the check box at Repository Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require branches to be up to date before merging ?
Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm not sure how we got to that state. Any other reasons to prefer on versus off?
On Mon, May 28, 2018, 09:11 Brett Cannon firstname.lastname@example.org wrote:
Ryan is right that there's no special setting in GitHub at least which would make merging more strict for certain branches as you're describing.
On Mon, 28 May 2018 at 07:06 Ryan Gonzalez email@example.com wrote: AFAIK there's no setting like this available, and I've done this many times on other repos with no trouble. Maybe it could be a GitHub bug?
On May 28, 2018 4:59:03 AM Victor Stinner firstname.lastname@example.org wrote:
Since one or two weeks, I noticed that it's difficult to merge pull requests into the 2.7 branch. If a different commit is pushed in the meanwhile (if a different PR has been merged), the 2.7 branch diverges and the PR is immediately marked as "This branch is out-of-date with the base branch" and the "Squash and Merge" button is disabled (grey).
For example my PR https://github.com/python/cpython/pull/7120 which changes Lib/test/regrtest.py cannot be merged because a commit touching the documentation (Doc/ directory) has been merged after I posted my PR and before the CI completed.
I don't see the same behavior on the master branch. Is the 2.7 branch configured as more strict?
-- Ned Deily email@example.com --