(Please note that this is my personal opinion, not a project-wide position or any sort of mandate.)
Back in August, I proposed that we should start experimenting with pull requests, by allowing their use for those who wanted to try them, but continuing to work with email-based patches for those that preferred that approach.
Compared with sending patches to the list, a pull request involves pushing a topic branch to your fork of the project on GitHub, and then sending a request that the project pull those changes in. (If you’re not familiar, you can read instructions on Using Pull Requests on GitHub.)
While I was admittedly biased, given that I was the one the proposed the idea, I’ve taken a liking to using pull requests, for a few reasons:
- The flow feels more intuitive to me when authoring patches. I write patches and push them to a branch. When I want to share them, I pull up GitHub and click a button. (This may be more a statement on how much I dislike git-send-email.)
- Applying patches from others is much easier. I just pull their branch, as compared to saving patches to disk (or piping them from mutt) and feeding them to git-am.
- It’s visual. While there’s nothing stopping me from opening patches in my favorite editor (either with patch emails or pull requests), for shorter patches I usually read them in my email client, and for longer patches I’d rather see all the changed files together in the GitHub interface than have to open various files in my text editor.
- Travis automatically tests our pull requests. This is my favorite feature, by far. When I’m reviewing someone else’s patch, I don’t have to sit waiting to see if automated tests work. Travis does that for me, leaving me to do the stuff humans are better at, like reading the code and running it to see if it works smoothly.
Of course, sending patches by email still has its fans, and there are some that just don’t like using GitHub. But for me, I’m in love with pull requests, especially with Travis’ help.