Specifying the latest SHA as part of the merge would solve the trust problem. As other people have mentioned, allowing a final "review and fixup this patch" ste

Specifying the latest SHA as part of the merge would solve the trust problem. As other people have mentioned, allowing a final "review and fixup this patch" step before merging would also be useful for some workflows; this is what happens when you merge on the command line. That leaves another major problem for us (the XS developers) which is that we actively encourage all development discussion and code review to be done on the mailing list where everyone involved sees it. With GH pull requests this discussion gets fragmented into separate threads on the various pull requests. Further, in my workflow, pulling in new changes to be committed into a pull request makes that pull request a new (version of) the original. See for example how Linux patches are discussed; you post an initial version, it gets discussed, you rework it, post a v2, and so on. At each point in time it is clear what exactly is being discussed. Personally I have some other philosophical issues with GH that might be fun to discuss, get in touch by email if you're interested.