• Nick Sabalausky (8/8) Mar 17 2011 I was thinking of converting my patches for various rdmd issues into git...
• Jonathan M Davis (20/29) Mar 17 2011 Not possible. A pull request is for an entire branch. It's all or nothin...
• Jesse Phillips (3/10) Mar 18 2011 I thought when you were doing a pull request you could do whatever you w...
• Jonathan M Davis (19/33) Mar 18 2011 You have all of git's capabilities when you do a pull request. You could...
• Don (5/40) Mar 18 2011 There's a bit of a confidence thing: if you're confident that ALL of the...
• Jonathan M Davis (5/42) Mar 17 2011 I committed a change to the pull request with a change to enforce's
• Jonathan M Davis (3/47) Mar 17 2011 Gag. I replied to the wrong post. LOL.
• Lars T. Kyllingstad (7/19) Mar 18 2011 You need a separate branch for each pull request. Commits which depend
• Don (8/30) Mar 18 2011 Cherry-picking works brilliantly in git. You don't need to worry about

"Nick Sabalausky" <a a.a> writes:

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?

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

- 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?

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Jesse Phillips <jessekphillips+D gmail.com> writes:

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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Don <nospam nospam.com> writes:

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).

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday 17 March 2011 20:23:08 Jonathan M Davis wrote:
 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.

Gag. I replied to the wrong post. LOL.

- Jonathan M Davis

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

On Thu, 17 Mar 2011 20:59:54 -0400, 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?
 
 - One branch with a separate commit for each issue, and a pull request
 for each commit?
 
 - 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?

You need a separate branch for each pull request.  Commits which depend 
on each other should of course be in a single branch.  Other than that, I 
would recommend creating a separate branch/pull req. for each issue.  
That way, if the patch for issue X isn't approved, the patches for Y and 
Z can still be merged in.

-Lars

Don <nospam nospam.com> writes:

Lars T. Kyllingstad wrote:
 On Thu, 17 Mar 2011 20:59:54 -0400, 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?

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

 - 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?

 
 You need a separate branch for each pull request.  Commits which depend 
 on each other should of course be in a single branch.  Other than that, I 
 would recommend creating a separate branch/pull req. for each issue.  
 That way, if the patch for issue X isn't approved, the patches for Y and 
 Z can still be merged in.
 
 -Lars

Cherry-picking works brilliantly in git. You don't need to worry about 
that. I would say, it's perfectly fine for multiple simple commits (each 
with 1-3 lines changed) to reside in the same branch.
Something that involves many changes, especially to multiple files, 
should be in its own branch.
If you create multiple branches and pull requests, each for single-line 
changes, you're just creating busywork.