Q on patch submission

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Q on patch submission

Sharp, Gregory C.
Hi all,

I am working through the instructions in the wiki [1].  For the record, I always die on the third screen in git.

Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?  Also, do I understand correctly that I should make sure that my clone has a git remote, and then I should fork the repository.  What does that mean?  Don't I need to fork first?

Thanks!
Greg

[1] https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F


       

_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

Nicole Aucoin
I always start with the steps here:
Once you've got that step done and the one following (push to your own repo), you can start at step 3 in the contribute a patch workflow.

Nicole

On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]> wrote:
Hi all,

I am working through the instructions in the wiki [1].  For the record, I always die on the third screen in git.

Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?  Also, do I understand correctly that I should make sure that my clone has a git remote, and then I should fork the repository.  What does that mean?  Don't I need to fork first?

Thanks!
Greg

[1] https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ



--
Nicole Aucoin
Harmonus Inc.
Harvard Launch Lab
114 Western Ave, Allston, MA 02134

_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

Steve Pieper-2
In reply to this post by Sharp, Gregory C.
Hi Greg -

Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

If it's a small fix, like pasting in the code from the upstream or a new superbuild hash you can even do the whole thing in the browser from the github interface (edit the code in place).

HTH,
Steve

On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]> wrote:
Hi all,

I am working through the instructions in the wiki [1].  For the record, I always die on the third screen in git.

Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?  Also, do I understand correctly that I should make sure that my clone has a git remote, and then I should fork the repository.  What does that mean?  Don't I need to fork first?

Thanks!
Greg

[1] https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

lasso2

> Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

 

I always follow this workflow for pull requests and it is really simple. If we all agree on this workflow then probably the best is to remove any other potential workflow descriptions to reduce confusion.

 

Andras

 

From: slicer-devel [mailto:[hidden email]] On Behalf Of Steve Pieper
Sent: March 15, 2017 16:52
To: Sharp, Gregory C. <[hidden email]>
Cc: SPL Slicer Devel <[hidden email]>
Subject: Re: [slicer-devel] Q on patch submission

 

Hi Greg -

 

Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

 

If it's a small fix, like pasting in the code from the upstream or a new superbuild hash you can even do the whole thing in the browser from the github interface (edit the code in place).

 

HTH,

Steve

 

On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]> wrote:

Hi all,

I am working through the instructions in the wiki [1].  For the record, I always die on the third screen in git.

Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?  Also, do I understand correctly that I should make sure that my clone has a git remote, and then I should fork the repository.  What does that mean?  Don't I need to fork first?

Thanks!
Greg

[1] https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

Sharp, Gregory C.
Awesome.  Thanks!  Edit-in-place is really very cool (I tried it out), and I will attempt that next time.
Based on the concept of fork, clone, edit, and push, I skipped the step "git remote add ..." in the wiki, and proceeded with this:

git checkout -b 4268-jsoncpp-on-gcc6
<edit source code>

Now, either "git push" or "git push 4268-jsoncpp-on-gcc6" fail with error message

fatal: The current branch 4268-jsoncpp-on-gcc6 has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin 4268-jsoncpp-on-gcc6

So, should I do that?  Or I should create a remote branch?  (Or are those two concepts the same?)

-Greg


From: slicer-devel [[hidden email]] on behalf of Andras Lasso [[hidden email]]
Sent: Wednesday, March 15, 2017 4:56 PM
To: Steve Pieper; Sharp, Gregory C.
Cc: SPL Slicer Devel
Subject: Re: [slicer-devel] Q on patch submission

> Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

 

I always follow this workflow for pull requests and it is really simple. If we all agree on this workflow then probably the best is to remove any other potential workflow descriptions to reduce confusion.

 

Andras

 

From: slicer-devel [mailto:[hidden email]] On Behalf Of Steve Pieper
Sent: March 15, 2017 16:52
To: Sharp, Gregory C. <[hidden email]>
Cc: SPL Slicer Devel <[hidden email]>
Subject: Re: [slicer-devel] Q on patch submission

 

Hi Greg -

 

Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

 

If it's a small fix, like pasting in the code from the upstream or a new superbuild hash you can even do the whole thing in the browser from the github interface (edit the code in place).

 

HTH,

Steve

 

On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]> wrote:

Hi all,

I am working through the instructions in the wiki [1].  For the record, I always die on the third screen in git.

Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?  Also, do I understand correctly that I should make sure that my clone has a git remote, and then I should fork the repository.  What does that mean?  Don't I need to fork first?

Thanks!
Greg

[1] https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

Jean-Christophe Fillion-Robin
Hi,

Using the hub command line (as an alias to git) also streamline working with github.

See https://hub.github.com/

Hth
Jc

On Wed, Mar 15, 2017 at 6:09 PM, Sharp, Gregory C. <[hidden email]> wrote:
Awesome.  Thanks!  Edit-in-place is really very cool (I tried it out), and I will attempt that next time.
Based on the concept of fork, clone, edit, and push, I skipped the step "git remote add ..." in the wiki, and proceeded with this:

git checkout -b 4268-jsoncpp-on-gcc6
<edit source code>

Now, either "git push" or "git push 4268-jsoncpp-on-gcc6" fail with error message

fatal: The current branch 4268-jsoncpp-on-gcc6 has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin 4268-jsoncpp-on-gcc6

So, should I do that?  Or I should create a remote branch?  (Or are those two concepts the same?)

-Greg


From: slicer-devel [[hidden email]] on behalf of Andras Lasso [[hidden email]]
Sent: Wednesday, March 15, 2017 4:56 PM
To: Steve Pieper; Sharp, Gregory C.
Cc: SPL Slicer Devel

Subject: Re: [slicer-devel] Q on patch submission

> Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

 

I always follow this workflow for pull requests and it is really simple. If we all agree on this workflow then probably the best is to remove any other potential workflow descriptions to reduce confusion.

 

Andras

 

From: slicer-devel [mailto:[hidden email]] On Behalf Of Steve Pieper
Sent: March 15, 2017 16:52
To: Sharp, Gregory C. <[hidden email]>
Cc: SPL Slicer Devel <[hidden email]>
Subject: Re: [slicer-devel] Q on patch submission

 

Hi Greg -

 

Yes, you can fork first on github, then clone that, push back to it, and then do the pull request.  I think that's a little easier.  

 

If it's a small fix, like pasting in the code from the upstream or a new superbuild hash you can even do the whole thing in the browser from the github interface (edit the code in place).

 

HTH,

Steve

 

On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]> wrote:

Hi all,

I am working through the instructions in the wiki [1].  For the record, I always die on the third screen in git.

Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?  Also, do I understand correctly that I should make sure that my clone has a git remote, and then I should fork the repository.  What does that mean?  Don't I need to fork first?

Thanks!
Greg

[1] https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ



--
+1 919 869 8849

_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

andrey.fedorov
Greg, would it make sense to offer this patch to the jsoncpp folks too?

On Wed, Mar 15, 2017 at 6:54 PM, Jean-Christophe Fillion-Robin
<[hidden email]> wrote:

> Hi,
>
> Using the hub command line (as an alias to git) also streamline working with
> github.
>
> See https://hub.github.com/
>
> Hth
> Jc
>
> On Wed, Mar 15, 2017 at 6:09 PM, Sharp, Gregory C. <[hidden email]>
> wrote:
>>
>> Awesome.  Thanks!  Edit-in-place is really very cool (I tried it out), and
>> I will attempt that next time.
>> Based on the concept of fork, clone, edit, and push, I skipped the step
>> "git remote add ..." in the wiki, and proceeded with this:
>>
>> git checkout -b 4268-jsoncpp-on-gcc6
>> <edit source code>
>>
>> Now, either "git push" or "git push 4268-jsoncpp-on-gcc6" fail with error
>> message
>>
>> fatal: The current branch 4268-jsoncpp-on-gcc6 has no upstream branch.
>> To push the current branch and set the remote as upstream, use
>>
>>     git push --set-upstream origin 4268-jsoncpp-on-gcc6
>>
>> So, should I do that?  Or I should create a remote branch?  (Or are those
>> two concepts the same?)
>>
>> -Greg
>>
>> ________________________________
>> From: slicer-devel [[hidden email]] on behalf of
>> Andras Lasso [[hidden email]]
>> Sent: Wednesday, March 15, 2017 4:56 PM
>> To: Steve Pieper; Sharp, Gregory C.
>> Cc: SPL Slicer Devel
>>
>> Subject: Re: [slicer-devel] Q on patch submission
>>
>> > Yes, you can fork first on github, then clone that, push back to it, and
>> > then do the pull request.  I think that's a little easier.
>>
>>
>>
>> I always follow this workflow for pull requests and it is really simple.
>> If we all agree on this workflow then probably the best is to remove any
>> other potential workflow descriptions to reduce confusion.
>>
>>
>>
>> Andras
>>
>>
>>
>> From: slicer-devel [mailto:[hidden email]] On Behalf
>> Of Steve Pieper
>> Sent: March 15, 2017 16:52
>> To: Sharp, Gregory C. <[hidden email]>
>> Cc: SPL Slicer Devel <[hidden email]>
>> Subject: Re: [slicer-devel] Q on patch submission
>>
>>
>>
>> Hi Greg -
>>
>>
>>
>> Yes, you can fork first on github, then clone that, push back to it, and
>> then do the pull request.  I think that's a little easier.
>>
>>
>>
>> If it's a small fix, like pasting in the code from the upstream or a new
>> superbuild hash you can even do the whole thing in the browser from the
>> github interface (edit the code in place).
>>
>>
>>
>> HTH,
>>
>> Steve
>>
>>
>>
>> On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]>
>> wrote:
>>
>> Hi all,
>>
>> I am working through the instructions in the wiki [1].  For the record, I
>> always die on the third screen in git.
>>
>> Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set
>> remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the fork?
>> Also, do I understand correctly that I should make sure that my clone has a
>> git remote, and then I should fork the repository.  What does that mean?
>> Don't I need to fork first?
>>
>> Thanks!
>> Greg
>>
>> [1]
>> https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F
>>
>>
>>
>>
>> _______________________________________________
>> slicer-devel mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to [hidden email] with
>> unsubscribe as the subject
>>
>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>
>>
>>
>>
>> _______________________________________________
>> slicer-devel mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to [hidden email] with
>> unsubscribe as the subject
>>
>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>
>
>
>
> --
> +1 919 869 8849
>
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

Sharp, Gregory C.

Hi,

Pull request sent.    

To answer my own question, it seems "yes" that extra step is needed.
If everyone agrees I will update the wiki which describes the
patch submission procedure.

The patch is actually from jsoncpp, so I don't think worth
sending to them.

Greg


On Thu, 16 Mar 2017 01:35:09 +0000
Andrey Fedorov <[hidden email]> wrote:

> Greg, would it make sense to offer this patch to the jsoncpp folks too?
>
> On Wed, Mar 15, 2017 at 6:54 PM, Jean-Christophe Fillion-Robin
> <[hidden email]> wrote:
> > Hi,
> >
> > Using the hub command line (as an alias to git) also streamline working
> > with github.
> >
> > See https://hub.github.com/
> >
> > Hth
> > Jc
> >
> > On Wed, Mar 15, 2017 at 6:09 PM, Sharp, Gregory C. <[hidden email]>
> > wrote:
> >>
> >> Awesome.  Thanks!  Edit-in-place is really very cool (I tried it out),
> >> and I will attempt that next time.
> >> Based on the concept of fork, clone, edit, and push, I skipped the step
> >> "git remote add ..." in the wiki, and proceeded with this:
> >>
> >> git checkout -b 4268-jsoncpp-on-gcc6
> >> <edit source code>
> >>
> >> Now, either "git push" or "git push 4268-jsoncpp-on-gcc6" fail with error
> >> message
> >>
> >> fatal: The current branch 4268-jsoncpp-on-gcc6 has no upstream branch.
> >> To push the current branch and set the remote as upstream, use
> >>
> >>     git push --set-upstream origin 4268-jsoncpp-on-gcc6
> >>
> >> So, should I do that?  Or I should create a remote branch?  (Or are those
> >> two concepts the same?)
> >>
> >> -Greg
> >>
> >> ________________________________
> >> From: slicer-devel [[hidden email]] on behalf of
> >> Andras Lasso [[hidden email]]
> >> Sent: Wednesday, March 15, 2017 4:56 PM
> >> To: Steve Pieper; Sharp, Gregory C.
> >> Cc: SPL Slicer Devel
> >>
> >> Subject: Re: [slicer-devel] Q on patch submission
> >>
> >> > Yes, you can fork first on github, then clone that, push back to it,
> >> > and then do the pull request.  I think that's a little easier.
> >>
> >>
> >>
> >> I always follow this workflow for pull requests and it is really simple.
> >> If we all agree on this workflow then probably the best is to remove any
> >> other potential workflow descriptions to reduce confusion.
> >>
> >>
> >>
> >> Andras
> >>
> >>
> >>
> >> From: slicer-devel [mailto:[hidden email]] On
> >> Behalf Of Steve Pieper
> >> Sent: March 15, 2017 16:52
> >> To: Sharp, Gregory C. <[hidden email]>
> >> Cc: SPL Slicer Devel <[hidden email]>
> >> Subject: Re: [slicer-devel] Q on patch submission
> >>
> >>
> >>
> >> Hi Greg -
> >>
> >>
> >>
> >> Yes, you can fork first on github, then clone that, push back to it, and
> >> then do the pull request.  I think that's a little easier.
> >>
> >>
> >>
> >> If it's a small fix, like pasting in the code from the upstream or a new
> >> superbuild hash you can even do the whole thing in the browser from the
> >> github interface (edit the code in place).
> >>
> >>
> >>
> >> HTH,
> >>
> >> Steve
> >>
> >>
> >>
> >> On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]>
> >> wrote:
> >>
> >> Hi all,
> >>
> >> I am working through the instructions in the wiki [1].  For the record, I
> >> always die on the third screen in git.
> >>
> >> Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set
> >> remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the
> >> fork? Also, do I understand correctly that I should make sure that my
> >> clone has a git remote, and then I should fork the repository.  What
> >> does that mean? Don't I need to fork first?
> >>
> >> Thanks!
> >> Greg
> >>
> >> [1]
> >> https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> slicer-devel mailing list
> >> [hidden email]
> >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> >> To unsubscribe: send email to [hidden email] with
> >> unsubscribe as the subject
> >>
> >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> slicer-devel mailing list
> >> [hidden email]
> >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> >> To unsubscribe: send email to [hidden email] with
> >> unsubscribe as the subject
> >>
> >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
> >
> >
> >
> >
> > --
> > +1 919 869 8849
> >
> > _______________________________________________
> > slicer-devel mailing list
> > [hidden email]
> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> > To unsubscribe: send email to [hidden email] with
> > unsubscribe as the subject
> > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Q on patch submission

Steve Pieper-2
Yes, updating the procedure on the wiki would be great and we can edit or add in commentary there.

Thanks Greg.

-Steve

On Thu, Mar 16, 2017 at 7:25 AM, Sharp, Gregory C. <[hidden email]> wrote:

Hi,

Pull request sent.

To answer my own question, it seems "yes" that extra step is needed.
If everyone agrees I will update the wiki which describes the
patch submission procedure.

The patch is actually from jsoncpp, so I don't think worth
sending to them.

Greg


On Thu, 16 Mar 2017 01:35:09 +0000
Andrey Fedorov <[hidden email]> wrote:

> Greg, would it make sense to offer this patch to the jsoncpp folks too?
>
> On Wed, Mar 15, 2017 at 6:54 PM, Jean-Christophe Fillion-Robin
> <[hidden email]> wrote:
> > Hi,
> >
> > Using the hub command line (as an alias to git) also streamline working
> > with github.
> >
> > See https://hub.github.com/
> >
> > Hth
> > Jc
> >
> > On Wed, Mar 15, 2017 at 6:09 PM, Sharp, Gregory C. <[hidden email]>
> > wrote:
> >>
> >> Awesome.  Thanks!  Edit-in-place is really very cool (I tried it out),
> >> and I will attempt that next time.
> >> Based on the concept of fork, clone, edit, and push, I skipped the step
> >> "git remote add ..." in the wiki, and proceeded with this:
> >>
> >> git checkout -b 4268-jsoncpp-on-gcc6
> >> <edit source code>
> >>
> >> Now, either "git push" or "git push 4268-jsoncpp-on-gcc6" fail with error
> >> message
> >>
> >> fatal: The current branch 4268-jsoncpp-on-gcc6 has no upstream branch.
> >> To push the current branch and set the remote as upstream, use
> >>
> >>     git push --set-upstream origin 4268-jsoncpp-on-gcc6
> >>
> >> So, should I do that?  Or I should create a remote branch?  (Or are those
> >> two concepts the same?)
> >>
> >> -Greg
> >>
> >> ________________________________
> >> From: slicer-devel [[hidden email]] on behalf of
> >> Andras Lasso [[hidden email]]
> >> Sent: Wednesday, March 15, 2017 4:56 PM
> >> To: Steve Pieper; Sharp, Gregory C.
> >> Cc: SPL Slicer Devel
> >>
> >> Subject: Re: [slicer-devel] Q on patch submission
> >>
> >> > Yes, you can fork first on github, then clone that, push back to it,
> >> > and then do the pull request.  I think that's a little easier.
> >>
> >>
> >>
> >> I always follow this workflow for pull requests and it is really simple.
> >> If we all agree on this workflow then probably the best is to remove any
> >> other potential workflow descriptions to reduce confusion.
> >>
> >>
> >>
> >> Andras
> >>
> >>
> >>
> >> From: slicer-devel [mailto:[hidden email]] On
> >> Behalf Of Steve Pieper
> >> Sent: March 15, 2017 16:52
> >> To: Sharp, Gregory C. <[hidden email]>
> >> Cc: SPL Slicer Devel <[hidden email]>
> >> Subject: Re: [slicer-devel] Q on patch submission
> >>
> >>
> >>
> >> Hi Greg -
> >>
> >>
> >>
> >> Yes, you can fork first on github, then clone that, push back to it, and
> >> then do the pull request.  I think that's a little easier.
> >>
> >>
> >>
> >> If it's a small fix, like pasting in the code from the upstream or a new
> >> superbuild hash you can even do the whole thing in the browser from the
> >> github interface (edit the code in place).
> >>
> >>
> >>
> >> HTH,
> >>
> >> Steve
> >>
> >>
> >>
> >> On Wed, Mar 15, 2017 at 4:45 PM, Sharp, Gregory C. <[hidden email]>
> >> wrote:
> >>
> >> Hi all,
> >>
> >> I am working through the instructions in the wiki [1].  For the record, I
> >> always die on the third screen in git.
> >>
> >> Just to confirm, the workflow is (1) clone, then (2) fork, then (3) set
> >> remote.  Seems weird.  Can I not instead (1) fork, then (2) clone the
> >> fork? Also, do I understand correctly that I should make sure that my
> >> clone has a git remote, and then I should fork the repository.  What
> >> does that mean? Don't I need to fork first?
> >>
> >> Thanks!
> >> Greg
> >>
> >> [1]
> >> https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_contribute_a_patch_.3F
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> slicer-devel mailing list
> >> [hidden email]
> >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> >> To unsubscribe: send email to [hidden email] with
> >> unsubscribe as the subject
> >>
> >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> slicer-devel mailing list
> >> [hidden email]
> >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> >> To unsubscribe: send email to [hidden email] with
> >> unsubscribe as the subject
> >>
> >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
> >
> >
> >
> >
> > --
> > <a href="tel:%2B1%20919%20869%208849" value="&#43;19198698849">+1 919 869 8849
> >
> > _______________________________________________
> > slicer-devel mailing list
> > [hidden email]
> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> > To unsubscribe: send email to [hidden email] with
> > unsubscribe as the subject
> > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ