Repository navigation
Preferred cloning URL #130
Description
Activity
The second form is the one GitHub offers for "Clone with HTTPS", while the last is the one it offers for "Clone with SSH", so I think it makes sense to stick with recommending those two and suggest:
- the HTTPS form for "read-only" clones
- the SSH form for "read-write" clones
The default recommended flow would then be:
-
Fork the cpython repo through the GitHub UI
-
Clone your fork:
git clone git@github.com:<your GitHub user name>/cpython.git -
Add a read-only
upstreamremote:cd cpython git remote add upstream https://github.com/python/cpython.git git fetch upstream
Folks following the "lazy fork" model just reverse the roles of the two URLs:
-
Clone the upstream repository directly:
git clone https://github.com/python/cpython.git -
Fork the cpython repo through the GitHub UI
-
Add a read-write
prremote:cd cpython git remote add pr git@github.com:<your GitHub user name>/cpython.git
Note that technically we don't have "read-write" clones anymore since we can't push directly to any branches on python/cpython. In any case, +1 for making the upstream (python/cpython)-origin (yourfork/cpython) model the default recommendation.
By read-write clones, I was referring to clones-of-your-fork, vs read-only clones of the primary repo.
Reacted by Louis RawlinsAdvantages of the https form:
- It works better behind a proxy (corporate proxies often don't allow custom protocols like git).
- You're using a consistent form for everything.
The https form prompts for a password each time, but you can set up a git credential manager to address that (Windows git comes with git credential manager as part of the install).
I like how GitLab recommends getting a local copy of a pull request (which they call merge requests). They recommend using
git fetchto grab the branch, thengit co -b <name> FETCH_HEADto check the branch out. I just fine it more intuitive, and easier to rebase locally, etc. Just FYI.E.g. from a Mailman MR:
git fetch git@gitlab.com:msapiro/mailman.git alias_domains git checkout -b msapiro/mailman-alias_domains FETCH_HEADI usually substitute something shorter for the
-boption, e.g.-b issue1234- Clone your fork:
git clone git@github.com:<your GitHub user name>/cpython.git-
Clone your fork. Choose one of the following:
SSH (when you have an SSH key set up for GitHub)
git clone git@github.com:<your GitHub user name>/cpython.gitHTTPS (when you do not have an SSH key set up or you are behind a proxy)
git clone https://github.com/<your GitHub user name>/cpython.git
Closed by #140
So far I met a few different ways to get a clone:
AFAICT there is no difference between the first two but when I use those it asks me for user/password whenever I try to push something, whereas if I use the third way it doesn't.
Is there a preferred form that we should use in the devguide? Are there other differences that should be noted? Do contributors and core devs use the same URL?