On Fri, 1 Apr 2016 at 12:34 Donald Stufft <donald.stufft@gmail.com> wrote:
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 and the resulting single commit 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.