Should I accept pull requests that are behind master?

Question

Sometimes my project has multiple pull requests. I don't know what is the proper process to handle it.

Currently what I do is

• Review each pull request.
• check code looks ok, and all comments were treated
• check if travis-ci passed and if github can auto-merge the request

if all of the above is correct, I accept the pull request.

However, there is a problem. Once I accepted the first pull request, all other pull requests are actually outdated.

This process encourages mistakes because:

• Travis should check the pull request again, but doesn't
• The developers should update their branch and reverify things work.

But, this process is not perfect too.

• The process creates a bottleneck on merging pull requests.
• There is no way for me to know when branch was merged - github does not indicate that "this pull request is 1 commit behind". So it requires me to do a manual comparison.
• It is hard to enforce or to define as best practice.

My question is - what is the proper way to handle accumulated pull requests on my project?

• Should every pull request be updated if master changes?
• How to make the CI tool (in my case travis) to run again if the destination branch changed as well..

Answer 1

Accepting pull requests that are slightly behind master seems perfectly fine to me, unless there's a strong reason to believe that conflicts are likely.

Ideally most of your pull requests should be on different parts of the codebase, and those parts should be decoupled enough that any one of them is very unlikely to break most of the others. In this case, forcing all but one of the requesters to update their pull requests is little more than red tape.

Also, in many cases it should be possible for you to verify things work when you accept these requests, because 1) you have automated tests (right?) and 2) pull requests should come with a minimal code example that is either fixed or enabled by that pull request, or at least a detailed enough description to produce such an example.

But what if you have several pull requests that clearly will conflict with each other? If they're all trying to do the same thing, pick the best one and ask the other requesters to test it to make sure it fixes the problem for everyone. If they're all trying to do different things to the same piece of code, and there's no sane way to detangle them (this should be very rare!), then I would bite the bullet and try doing some git surgery to combine them into a single pull request that you can ask everyone to test before accepting.