Pull requests for multiple issues?

[Jonathan M Davis]

On Thursday 17 March 2011 18:43:33 Jonathan M Davis wrote:
> 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.

I committed a change to the pull request with a change to enforce's 
documentation to mention that it's intended to aid in error handling, not 
verifying the logic of programs.

- Jonathan M Davis