You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2012/07/12 22:18:15 UTC
Integrating pull-requests
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.
Re: Integrating pull-requests
Posted by Shazron <sh...@gmail.com>.
Thank you!
On Fri, Jul 27, 2012 at 11:50 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Done! http://wiki.apache.org/cordova/CommitterWorkflow
>
>
> On Thu, Jul 26, 2012 at 5:14 PM, Shazron <sh...@gmail.com> wrote:
>
>> 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 <ag...@google.com> 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 <sh...@gmail.com> 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.
>> >>
>>
Re: Integrating pull-requests
Posted by Andrew Grieve <ag...@chromium.org>.
Done! http://wiki.apache.org/cordova/CommitterWorkflow
On Thu, Jul 26, 2012 at 5:14 PM, Shazron <sh...@gmail.com> wrote:
> 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 <ag...@google.com> 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 <sh...@gmail.com> 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.
> >>
>
Re: Integrating pull-requests
Posted by Shazron <sh...@gmail.com>.
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 <ag...@google.com> 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 <sh...@gmail.com> 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.
>>
Re: Integrating pull-requests
Posted by Andrew Grieve <ag...@google.com>.
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 <sh...@gmail.com> 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.
>