What Git workflow do I need to use to be able to compare a PR branch before and after an author's force push?

Question

This is more of a Git question but it is particularly relevant to Bitcoin Core PR review (or other open source projects with stringent review requirements).

You've done a review of a PR, the PR author force pushes and you want to compare the PR branch before the force push and after the force push. I've read you should use git range-diff in this scenario. But I'm not sure how to get Git to store the branch before the force push (the previous commit isn't in the Git history anymore) and compare to the latest version of the branch.

Answer 1

Git is like a blockchain: it only keeps the "best-commit-chain". A git push -f "reorgs" the prior chain of commits to a new "best chain".

If you checked out the PR before the force-push, your local git repository retains a copy of the commits from before the force-push. You can then use git fetch and git range-diff <branch> <upstream/branch> to compare the state prior and posterior of the force-push. If you have already checked out the updated branch after the force-push, your local repository still retains a copy of the prior commits (even if it doesn't show up in git log) and you can compare by calling git range-diff <old-commit-hash> <branch>. If you don't remember the old stale commit-chain-tip, you can look it up via git reflog.

Similarly to a Bitcoin node either having seen an extinct chain-tip when it was relevant or there being no (easy) way to get it, you cannot easily get an overwritten commit unless you created a local copy of the upstream branch before the force-push since overwritten commits are discarded by GitHub. In that case, just start reviewing from scratch.

---

TIL that GitHub meanwhile apparently does keep old commits around for a while. So, if you're lucky and it hasn't been cleaned up yet, you may be able to retrieve the "stale commit-chain-tip" via: git fetch upstream <commit-hash>

Answer 2

theStack and Jon Atack answered this on IRC.

What i usually do for reviewing is to give each revision of a PR another branch name locally, e.g. for a hypothetical PR #123456:

git fetch origin pull/123456/head:pr123456

Now the PR author force-pushes: git fetch origin pull/123456/head:pr123456_2

There are now two branches pr12346 and pr123456_2, and the differences can be shown with git range-diff pr123456...pr123456_2. This works on a repository that just cloned from the original Github repo without any changes to the configuration)

My Git update workflow runs something like git checkout master && git pull (this pulls down all the updated branches) && git checkout origin/pr/12345 (open gitk and/or run git range-diff, and then if I intend to build the PR I usually run git rebase origin/master before building, not only to check for merge conflicts but also to build more quickly from cache as it is usually up to date with latest master. I probably use git range-diff more often than git diff, as it provides the diff commit by commit. I customize my .gitconfig somewhat (e.g. for git diff, git fetch, git pull etc.) theStack's version might work better out of the box.

(achow101 uses git worktree when reviewing PRs on his Twitch stream.)

For more guidance on reviewing pull requests in Bitcoin Core see Jon Atack's blog post.