On Fri, 1 Apr 2016 at 12:34 Donald Stufft
Just wanted to point out a few new features from GitHub that may (or may not!) be useful for Python’s use of Github:
* Required status checks no longer requiring a branch to be up to date.
Previously turning on required status checks meant that to merge a branch into a protected branch, you the target branch could not contain any commits that didn’t exist in the PR. This effectively made the feature useless for OSS projects, but it could be useful now. Of course this would also mean that all changes need to happen via PR instead of directly pushing to a protected branch, so it may not still be useful for Python.
We have actually talked about trying to encourage all core devs to go through code review. Obviously that still only matters, though, if you merge through the GitHub UI, which leads to your next point ...
* Squash Merges, Regular Merges, or Both.
Previously the GitHub "Merge" button would always do a regular, no fast forward merge which kept all of the commits that the original author made intact. However GitHub now allows a repository to decide what kind of merges it allows, either that or sqaush merges (or it can allow both). If it allows both then the person doing the merge gets to pick what kind of merge I think.
A Squash merge will be most similar to how patches used to land on Python and would prevent history from getting clogged up with needless commits from people who don't edit history to keep their PRs clean, however it might lose history from people who do.
Wow! For those of you who, like me, didn't know about this, it was posted to the GitHub blog earlier today: https://github.com/blog/2141-squash-your-commits (I hope this isn't an elaborate April Fools prank). I have already tried this out on the CLA bot to see how it operates and it works as expected; you can see a PR with multiple commits https://github.com/python/the-knights-who-say-ni/pull/7 and the resulting single commit https://github.com/python/the-knights-who-say-ni/commit/d4baec1f1e209fc341a9... on the repo. This looks to give Guido that linear commit history he really wants for CPython! The trick, though, is that this doesn't handle merges into other branches and it doesn't cover Misc/NEWS. The question then becomes how to handle those situations. For the merge bit, if we switched from our idea of cherrypicking to sticking with our merge forward solution like we do in hg then you can manually create the merge-forward PR in GitHub's web UI which is no worse than how it operates now. And if there is a merge conflict then you can manually check out the PR, patch it up, and then be on your merry way. The issue with that is if your merge fails and you're not on a computer where you can fix up the merge as that could fall on someone else's shoulders who wants to do a merge while you wait to get home on a computer to do the fixing. I'm not sure how often that would really happen, though, as most merges are fairly clean. As for Misc/NEWS, we could stick with the plan of moving to a file-based solution but have external contributors actually write the NEWS entry. Core devs could then request any rewrite they have for the entry which wouldn't be a huge burden thanks to GitHub's in-browser editor. We could even go as far as having a Misc/NEWS status check that flags when there is no Misc/NEWS entry (that may be an issue, though, if in the future we choose to have commits be blocked by failing status checks; won't happen until our test suite is not flaky, though). So this support of squash merging *may* be useful. It really depends on how we try and support porting changes between versions and Misc/NEWS.