Why the make command?

I mentioned that in the commit message. You can't do any testing unless you run make after switching branches. If you forget the make, weird and mysterious things may happen.

@bitdancer It's likely more user friendly to separate out the make command to a separate paragraph.

Perhaps:

 Simply use ``git checkout`` to checkout another branch in the current directory::

    $ git branch
    * master
      3.5
    $ git checkout 3.5
    Switched to branch '3.5'
    Your branch is up-to-date with 'origin/3.5'.

To verify that your branch has been checked out, enter git branch. After changing branches, it's good practice to run make before executing the tests:

   $ git branch
       master
    * 3.5
   $ make
    $  make

This won't update the current local branch, correct? If so you might want to mention that.

OK, I'll reword that.

Talking about 'remote branches' is really a pain in git.

@bitdancer FWIW, we often teach contributors to fork the upstream repo and then clone their fork to their local system. This will give the following source locations:

• local computer
• origin: remote that corresponds to the user's fork of the upstream repo (i.e. url: https://github.com/<github_username>/cpython)
• upstream: remote that corresponds to the cpython official repo on GitHub

Here's a presentation that I recently gave on open source git and GitHub workflow including git fetch and git rebase use to minimize merge conflicts: http://www.slideshare.net/willingc/yes-you-can-git

Personally, I think a better way is to clone the project locally, then clone it on github, then create a remote (I use 'dev', one could use 'mine', 'mygithubclone', or whatever) pointing at your github clone, and then delete the master branch in your github clone[*]. That gives you 'orgin/master' for the project master, and 'dev/mybranch' for your local PRs, and no chance of confusing your github master with the project master.

However, I understand this style may not be what we want to recommend :)

[*] To do this you have to have created at least one branch (say, 'fakemaster'). Then you go into settings/branches in github and set your new branch as the default, and finally do 'git push --delete dev/master'.

Quite likely there will be several reasonable ways just as there are emacs, vim, atom, ... 😉

What may be useful is to link to the GitHub Bootcamp tutorial https://help.github.com/articles/fork-a-repo/ which walks through forking, cloning, setting up remotes.

I'm in the "origin = read-only original, pr = my clone" camp with David - the reason I do it this way is that there are a lot of repos where I first clone them just to tinker with them, and only later do I want to send a PR. At that point, adding a "pr" remote is easier than switching origin to point to my fork instead of upstream. (Being able to do "git checkout master && git pull" to get the latest upstream is then just an added bonus)

The default recommended GitHub workflow makes more sense in a work context (where of course you're going to make changes - that's your job!), but less so when you're exploring open source projects to understand them (and maybe build on top of them).

These are the only two major PR workflows I've encountered though, so I don't think there's a zoo of possibilities - just the default approach, and the common variant of keeping "origin" as upstream.

probably a typo: an -> and

I think using origin is a bit misleading here. origin will likely be the user's fork so unless they explicitly update their fork this command won't show the actual results. Perhaps we need to add a new FAQ entry about adding a new upstream remote and then use it here?

If you do so, please add an information how to sync one's fork with current master as well and how to rebase patches, imho. Both of these are valuable information.

Yes, I agree, this should be fixed and rebase should be mentioned. This is turning into a tutorial about using git for cpython development, though. Does it belong in the FAQ or is there somewhere better (and then this faq entry can link to it).

What I do is clone from the original repo, making that origin, and then add my github clone as the remote 'dev'.

+1 for the faq entry that can be then linked everywhere where appropriate.

Maybe we consider not keeping the FAQ around anymore and simply do a good tutorial for using git with cpython development? There's tons of docs online on how to use git unlike Mercurial back in the day, so maybe this whole file will lose its usefulness once we switch to GitHub?

That's my thought at this point: that a tutorial covering the actions one will want to do with regards to the CPython repo will be the most useful, specifically covering our workflow, including the interaction with the bug tracker. We'll need to fine tune it as we work the latter out.

OK, then let's just delete the FAQ. I created #27 to track the deletion of the FAW and #28 to track creating a tutorial.

Feel free to close this PR, @bitdancer , or if you want to take on the deletion and repurpose this PR then that's obviously fine as well.