Git and GitHub concepts: Reviewing updated pull requests locally

Question

I follow the generic OSS structure:

1. the OSS\' remote repository hosted on GitHub
2. a fork of the OSS remote repository to my own remote repository

Answer 1

The problem—or at least the first one—here is that you cannot use an upstream to refer to a GitHub pull request reference.

In Git, an upstream on a branch consists of two parts:

• The name of a remote, such as origin
• The name of a branch on that remote, such as master

Git puts these two together to get refs/heads/master—this is the name on the remote—then runs this string through the fetch setting(s) for the remote. The standard fetch setting for the remote named origin is +refs/heads/*:refs/remotes/origin/*, so if the upstream is currently set to the pair <origin, master>, the name that Git looks up in your own repository is refs/remotes/origin/master, which is your remote-tracking name for their master.

Note the assumption in here that the name on the remote begins with refs/heads/.

The actual name of a pull reference on GitHub begins with refs/pull/, not refs/heads/, so that the full name of the commit you want for pull request #123 is refs/pull/123/head. There is no way to spell this that starts with refs/heads/ because this is not a branch name.

Now, you can—as suggested in your first link—add an extra fetch setting:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

which causes their refs/pull/123/head to associate with your refs/remotes/origin/pr/123. Depending on your particular Git version, some of this sometimes or even mostly works. Some Git versions get rather confused at times. If you try it and it works for you, that's great, just be prepared to clean up a bit of a mess if you upgrade or downgrade Git versions for some reason.

The aliases found via your second link are better. These fetch from one specific pull request, creating a local branch name (or overwriting it if it already exists—this is a bit dangerous but as long as you don't name your own branches pr/integer you will be fine). You could improve them, writing a real git-pr script that creates a local branch—be sure to use the full name format, refs/heads/pr/number, to guarantee correctness—and sets some additional information so that, when you are on that branch, git pr updates the branch automatically.

(If I get some spare time, I might write my own script, because this would be pretty handy.)

Answer 2

You can use any of below options to update the PR in local repo.

Option 1: delete the local source branch and recreate to get the update

As you use the commands to get the source branch of the PR locally:

git fetch upstream pull/<PR#>/head:<branchName>
git checkout <branchname>

If the PR is updated (new commits are pushed to the fork repo), you can delete and recreate by:

git checkout master
git branch -D <branchname>
git fetch upstream pull/<PR#>/head:<branchName>
git checkout <branchname>

Option 2: add the fork repo as a remote for your local repo

You can add the fork repo as a remote for your local repo by

git remote add fork1 <URL for the fork repo> -f

Then you can create a local branch for the PR source branch by

git checkout -b <branchname> fork1/<branchname>

If the PR has been updated, you just need to execute below commands to get the update:

git fetch fork1
git checkout <branchname> #If HEAD is not on the <branchname>
git reset --hard fork1/<branchname>