Re: [python-committers] New workflow - some questions

2017-07-29 Thread Paul Moore
On 28 July 2017 at 23:30, Mariatta Wijaya  wrote:
>> 1. Section 32.2 in the Git bootcamp section - is there any reason to
>> use git@github URLs for the clones? I normally always use
>> https://github.com URLs, as they work with my proxy at work.
>
>
> I don't have any explanation other than Git bootcamp was initially written
> based on my personal setup.
> I cloned CPython using SSH, and that's what I wrote in the devguide :)
> You can use HTTPS if that works for you.
> Perhaps someone else can explain better the difference between cloning via
> HTTPS and SSH.

Thanks for the clarification - I doubt it matters much whether you use
https or git in practice. I've found https better for me because it's
more proxy friendly. I don't really know the differences because I've
never used git.

>> I generally use "Compare and create pull request"
>> from my clone's github page, as that seems simpler.
>
> Note that the link is only visible within 30 minutes (or so) after you
> pushed your branch to remote.

Ah - I didn't know that, When working on pip, I normally push and
create a PR in quick succession.

> If you did not create the PR immediately after pushing, the link disappears.
> In this case, the instructions in 32.10 will help (maybe?).

They will - a lot. Thanks.

> Can we assume that people will create their PR immediately?

Definitely not, in general.

> Maybe an improvement is to mention the "Compare and create pull request",
> and to do this immediately after pushing the branch.

It might be worth suggesting it as an option, simply so that if a
contributor sees the button, they know it's just an alternative
approach and it's OK to use. I'll see if I can think of some wording
that would help here.

> side-topic: Does anyone have some sort of script/git
> alias/program/whatchamacallit that will open the PR page once we push to
> remote? (similar to what cherry_picker does)  That could be a time saver :)

I don't - that's the sort of thing I just do manually. (I work on
multiple machines, so I'm heavily reliant on minimising the amount of
custom scripts and/or setup needed to work on a project. For me, a
simple, easily remembered workflow with minimal dependencies on
specialised tools works best.)

>> 3. The new blurb tool - I presume I'll need to set that up
>> somewhere/somehow, and use it to create a news entry. But I can't find
>> any docs on it at all :-(
>
> pip install blurb

Doh. I think I recall some discussion about using virtualenvs and
maybe that made me think something complex was needed. My mistake.

> Some write-up here:
> https://devguide.python.org/committing/#what-s-new-and-news-entries

Again doh - I don't know how I missed that, thanks.

> blurb readme:
> https://github.com/python/core-workflow/blob/master/blurb/README.rst

Paul
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] New workflow - some questions

2017-07-29 Thread Nick Coghlan
On 29 July 2017 at 18:40, Paul Moore  wrote:
> On 28 July 2017 at 23:30, Mariatta Wijaya  wrote:
>>> 1. Section 32.2 in the Git bootcamp section - is there any reason to
>>> use git@github URLs for the clones? I normally always use
>>> https://github.com URLs, as they work with my proxy at work.
>>
>>
>> I don't have any explanation other than Git bootcamp was initially written
>> based on my personal setup.
>> I cloned CPython using SSH, and that's what I wrote in the devguide :)
>> You can use HTTPS if that works for you.
>> Perhaps someone else can explain better the difference between cloning via
>> HTTPS and SSH.
>
> Thanks for the clarification - I doubt it matters much whether you use
> https or git in practice. I've found https better for me because it's
> more proxy friendly. I don't really know the differences because I've
> never used git.

To be honest, the read-only=HTTPS & read/write=SSH split is likely a
Linux+macOS-ism, where we can do "ssh-add" once, and then never have
to worry about explicitly authenticating again until we reboot our
client machine. As Inada-san notes, the password prompt when
accidentally doing a direct push to a HTTPS clone then serves as a
reminder that you probably meant to push to a different remote that's
set up for read/write access over SSH.

There's no functional difference on the server side though - it's
strictly about how the git client authenticates your identity with the
server.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] New workflow - some questions

2017-07-29 Thread Paul Moore
On 29 July 2017 at 14:13, Nick Coghlan  wrote:
> To be honest, the read-only=HTTPS & read/write=SSH split is likely a
> Linux+macOS-ism, where we can do "ssh-add" once, and then never have
> to worry about explicitly authenticating again until we reboot our
> client machine. As Inada-san notes, the password prompt when
> accidentally doing a direct push to a HTTPS clone then serves as a
> reminder that you probably meant to push to a different remote that's
> set up for read/write access over SSH.
>
> There's no functional difference on the server side though - it's
> strictly about how the git client authenticates your identity with the
> server.

On Windows you can use the git credential manager to store credentials
in the OS cert store, and then https is passwordless for push.

Paul
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] New workflow - some questions

2017-07-29 Thread Terry Reedy

On 7/29/2017 4:40 AM, Paul Moore wrote:

On 28 July 2017 at 23:30, Mariatta Wijaya  wrote:

1. Section 32.2 in the Git bootcamp section - is there any reason to
use git@github URLs for the clones? I normally always use
https://github.com URLs, as they work with my proxy at work.


As I understand it, https uses stored login credentials, git@ uses ssh 
key.  I use https always.



I generally use "Compare and create pull request"
from my clone's github page, as that seems simpler.


I often use my fork's 'branches' page, which always has 'pull request' 
buttons, and just leave it open.



side-topic: Does anyone have some sort of script/git
alias/program/whatchamacallit that will open the PR page once we push to
remote? (similar to what cherry_picker does)  That could be a time saver :)


If I type 'cp' in my browser url bar, github.com/python/cpython is at 
the top of my history list.  For 'te', github.com/terryjreedy is at the 
top.  They were initially further down, but present after a few visits. 
The first rose first, as 'cp' is a very uncommon pair.


Terry
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/