Pull requests for multiple issues?

[Jonathan M Davis]

On Thursday, March 17, 2011 17:59:54 Nick Sabalausky wrote:
> I was thinking of converting my patches for various rdmd issues into github
> pull requests, but being relatively new to DVCSes (longtime SVN user here)
> I was wondering what's the "kosher" way to do it?:
> 
> - A separate branch for each issue, with a pull request for each branch?

That's a valid way to do it.

> - One branch with a separate commit for each issue, and a pull request for
> each commit?

Not possible. A pull request is for an entire branch. It's all or nothing.

> - One branch with a separate commit for each issue, and a pull request for
> the whole branch? If so, the root of the branch or the leaf of the branch?

That would be the other way to do it, but as I said, a pull request is all or 
nothing, so the "root vs leaf" issue is irrelevant.

When you do a pull request you're asking for _all_ of the commits which are on 
your branch but not in the main repository to be merged into the main 
repository.

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.

Regardless, splitting up your changes into commits with each being a clear set 
of changes will make it easier to review (and thus accept and merge in) your 
code than if all of your changes are in one commit. So, having several commits 
is often a _good_ thing.

- Jonathan M Davis