Preferred cloning URL #130

Activity

1. ezio-melotti

   added

   question

   on Feb 23, 2017
2. ezio-melotti

   changed the title [-]Preferred cloning url[/-] [+]Preferred cloning URL[/+] on Feb 23, 2017
3. ncoghlan commented on Feb 23, 2017

   

   ncoghlan

   on Feb 23, 2017

   Last edited by ncoghlan

   Contributor

   More actions

   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:

   1. Fork the cpython repo through the GitHub UI

   2. Clone your fork:

       git clone git@github.com:<your GitHub user name>/cpython.git
      

   3. Add a read-only upstream remote:

       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:

   1. Clone the upstream repository directly:

       git clone https://github.com/python/cpython.git
      

   2. Fork the cpython repo through the GitHub UI

   3. Add a read-write pr remote:

       cd cpython
       git remote add pr git@github.com:<your GitHub user name>/cpython.git
      
4. berkerpeksag commented on Feb 23, 2017

   

   berkerpeksag

   on Feb 23, 2017

   Member

   More actions

   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.
5. ncoghlan commented on Feb 23, 2017

   

   ncoghlan

   on Feb 23, 2017

   Contributor

   More actions

   By read-write clones, I was referring to clones-of-your-fork, vs read-only clones of the primary repo.

   👍React with 👍1Reacted by Louis Rawlins
6. pfmoore commented on Feb 23, 2017

   

   pfmoore

   on Feb 23, 2017

   Member

   More actions

   Advantages of the https form:

   1. It works better behind a proxy (corporate proxies often don't allow custom protocols like git).
   2. 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).
7. warsaw commented on Feb 23, 2017

   

   warsaw

   on Feb 23, 2017

   Member

   More actions

   I like how GitLab recommends getting a local copy of a pull request (which they call merge requests). They recommend using git fetch to grab the branch, then git co -b <name> FETCH_HEAD to 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_HEAD
   

   I usually substitute something shorter for the -b option, e.g. -b issue1234
8. willingc commented on Feb 25, 2017

   

   willingc

   on Feb 25, 2017

   Collaborator

   More actions

   2. Clone your fork:

   git clone git@github.com:<your GitHub user name>/cpython.git
   

   2. 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.git
      

      HTTPS (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
      
9. willingc commented on Mar 19, 2018

   

   willingc

   on Mar 19, 2018

   Collaborator

   More actions

   Closed by #140
10. willingc

    closed this as completedon Mar 19, 2018