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