New workflow - some questions
I'm just looking at doing some work for the first time under the new workflow. Most things look fine - I'm familiar with git/github, so there's nothing startling in there, but I do have a few small questions:
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.
Section 32.10, I generally use "Compare and create pull request" from my clone's github page, as that seems simpler. Is there any reason for starting from the cpython repo - the process working that way (which I wasn't even aware of!) seems more complex. I can't see that it matters much, but I wouldn't want to mess up a PR if there *is* a difference in the results.
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 :-(
There may be other stuff - I've been watching the core-workflow list, and it feels like there's some awfully complex stuff being discussed. But so far it looks pretty straightforward and "as expected" - which is a credit to Brett and the others who've set all this up!
Thanks, Paul
- 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.
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. If you did not create the PR immediately after pushing, the link disappears. In this case, the instructions in 32.10 will help (maybe?). Can we assume that people will create their PR immediately? Maybe an improvement is to mention the "Compare and create pull request", and to do this immediately after pushing the branch.
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 :)
- 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
Some write-up here: https://devguide.python.org/committing/#what-s-new- and-news-entries blurb readme: https://github.com/python/core-workflow/blob/ master/blurb/README.rst
Mariatta Wijaya
On Sat, Jul 29, 2017 at 7:30 AM, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
- 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.
I usually uses https for "read-only" remote. Sometimes, even I have commit rights, I use pull request from personal fork and I don't want to push directly. Of course, I can use https to push. But it requires some additional steps. So it prevent accidental push to "origin".
I think there are no downside to use HTTPS for "read only" remotes.
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. If you did not create the PR immediately after pushing, the link disappears. In this case, the instructions in 32.10 will help (maybe?). Can we assume that people will create their PR immediately? Maybe an improvement is to mention the "Compare and create pull request", and to do this immediately after pushing the branch.
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 use Github's "hub" CLI. https://github.com/github/hub
"hub pull-request" can be used to create pull request from terminal. "hub browse" can be used to open browser for current branch.
Regards,
On 28 July 2017 at 23:30, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
- 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.)
- 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
On 29 July 2017 at 18:40, Paul Moore p.f.moore@gmail.com wrote:
On 28 July 2017 at 23:30, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
- 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 | ncoghlan@gmail.com | Brisbane, Australia
On 29 July 2017 at 14:13, Nick Coghlan ncoghlan@gmail.com 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
On 7/29/2017 4:40 AM, Paul Moore wrote:
On 28 July 2017 at 23:30, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
- 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
On Sat, 29 Jul 2017 at 09:05 Terry Reedy tjreedy@udel.edu wrote:
On 7/29/2017 4:40 AM, Paul Moore wrote:
On 28 July 2017 at 23:30, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
- 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.
GitHub has a page dedicated on helping you choose the approach: https://help.github.com/articles/which-remote-url-should-i-use/. For me personally, if I'm on Linux (and this includes WSL!) I use SSH, otherwise I use HTTPS with a credential helper (or put another way: if I can use a credential helper I use HTTPS, else use SSH).
participants (6)
-
Brett Cannon -
INADA Naoki -
Mariatta Wijaya -
Nick Coghlan -
Paul Moore -
Terry Reedy