Pull requests for multiple issues?

[Don]

Jonathan M Davis wrote:
> On Friday, March 18, 2011 07:26:38 Jesse Phillips wrote:
>> Jonathan M Davis Wrote:
>>> I would say that, generally speaking, unrelated changes should be
>>> separate pull requests, whereas related changes should be grouped
>>> together into a single pull request. Remember that it's all or nothing,
>>> so they're going to merge in all of your changes or none of them. So, if
>>> it makes sense for them to all go together, then put them together, but
>>> if they don't necessarily make sense to go together and it _would_ make
>>> sense to accept some of them but not all of them,  then separate them.
>> I thought when you were doing a pull request you could do whatever you
>> wanted to bring in the changes you wanted, such as cherry-picking.
>>
>> But I agree it makes review and acceptance easier. The reviewer should be
>> able/expected to accept all/nothing.
> 
> You have all of git's capabilities when you do a pull request. You could do the 
> pull request into your own branch and then cherry pick just the ones that you 
> want, certainly. However, the pull request itself is for the full branch. It's 
> not done by commits but by branch. And I would generally expect that a pull 
> request would contain a related set of changes such that cherry picking them 
> likely wouldn't make sense. However, as Don points out, if you have a lot of 
> unrelated changes which are small, then it could be desirable to have a single 
> pull request for all of them. Still, I wouldn't expect someone merging them in 
> to normally cherry pick the parts of a pull request that they thought were good. 
> That would create extra work too.
> 
> So, on the whole, I would expect pull requests to contain related changes which 
> should either be merged in as a whole on not merged in at all. Any further 
> commits to the branch before it's pulled in will be added to the pull request, 
> so reviewers can request that the person doing the pull request make any 
> necessary changes be made before it's pulled in, which should generally avoid 
> any need to cherry pick anything, even in cases where several smaller changes 
> were grouped together.
> 
> - Jonathan M Davis

There's a bit of a confidence thing: if you're confident that ALL of the 
patches are good, they're OK in one branch. But anything which you're 
less certain about should go in its own branch. (You'll get the most 
straightforward ones assessed and integrated more quickly that way).