Looks like the right procedure. A merge is generally the right way to go IMO, I would only cherry-pick if their pull request is 1 or 2 commits and it looks like their branch is really outdated, so I would avoid a merge mess (thus this will skip the requirement of them having to rebase then resubmit).
As for squash - that's problematic since it loses contributor info (I tried experimenting with it). On Thu, Jul 26, 2012 at 1:12 PM, Andrew Grieve <[email protected]> wrote: > I'd like wiki page to spell this out. Can someone have a look at the > following and tell me if it's correct? Any guidance on when to merge vs. > cherrypick? Do we ever want to use --squash? > > > One-time setup: > git remote add apache git://git.apache.org/incubator-cordova-ios.git > > Review the change: > - View the user's branch in github and request changes be made (if > applicable) by adding comments in the web interface > - Ensure that commit descriptions are accurate and that they reference any > related JIRA bugs. > > > git remote add foo git://github.com/user/incubator-cordova-ios.git > git fetch foo > git checkout master > git pull apache master > git merge --ff-only foo/branch_name > // If this fails, then ask committer to pull, rebase & push. Unless... is > there a way to resolve this if the merge is simple??? > git push apache master > git remote rm foo > > Update related JIRA issue with the commit ID and close it if appropriate. > Respond to pull request on github with link to their commit and ask them to > close pull request. > > > > On Thu, Jul 12, 2012 at 4:18 PM, Shazron <[email protected]> wrote: > >> Re: >> https://issues.apache.org/jira/browse/CB-765?focusedCommentId=13412936#comment-13412936 >> >> Just FYI if you are integrating pull requests it is important to >> maintain authorship history (merge or cherry pick), and not copy and >> paste the contributed code in. >>
