Sure you can force push it, but the reviewer has to review the whole branch all over again. No diff between versions of the branch.

Actually, the words 'force pushed' in the force push message on the PR (or very nearby to that), are a link to a diff between the pre and post push states of the branch.

You can also construct such a diff yourself by going to something like /compare/<old commit hash>..<new commit hash>, and those hashes can also be tags or branch names, and should even allow relative stuff like HEAD^.

(I haven't checked the URL just now, but I use both often. It's a little annoyingly hidden, but it is there.)

Yuck. That sounds like a github bug to me. bitbucket has its flaws, but this isn't one of them. We rebase review branches on a regular basis without difficulty and have a useable linear history as a result.

This is something that Gerrit is really good at. The model is a little weird, because it tracks all pushes to a code review essentially as separate commits. But it makes the workflow really really easy for reviewers: you can diff any two versions of the proposed patch. Github has no equivalent that I've found. You can look at a subset of individual commits in the PR, but they're not diffed against each other, which makes it harder to check that the one or two things you were concerned about have been addressed.

<plug>You might want to take a look at https://reviewable.io -- we can diff arbitrary commits without Gerrit's weird model, and a whole lot more besides. </plug>

You're still missing the point: diff of diffs. When GitHub compares two commits, it diffs the whole repo as of one commit against the other (like `git diff commitA commitB); what is requested is diffing the change contained in one commit against the other (like `diff <(git show commitA) <(git show commitB)`).

PS: I checked out your demo. I can't see how to diff arbitrary commits, only revisions of a PR.

IIUC, you're looking for true diffs between revisions with different bases. If so, Reviewable deals with that automatically, running 4 separate diffs in the background and integrating the results so that base-only diffs are hidden by default.

As for diffing commits, you can switch a review into "review each commit" mode so that it will create one revision per commit. You can make this the default for a repo but it's not in the demo as it's not the most common way to work. The demo does really need updating, though!

I do something in between. After the initial set of commits and review, I'll add a new commit 'Changes from PR review'. If there are additional changes from further review, I do usually amend and force push this commit.

If there are extensive changes from a follow-up review it gets its own commit and specific commit message.

Github shows the force push, and from which commit to which commit it happened. You can then manually put the into the diff view of Github and see what changed. I agree that it should have a UI though.

The diff view is unusable if master has moved in the meanwhile. What you really need is a UI for "git range-diff".

You can do that in azure devops. By default, it shows all commits and then you can go to the commits tab and select the ones you want to view ( multiple or single)

Can it show a diff-of-diffs, and detect patches that were added, removed or reordered? Something like https://patchew.org/QEMU/[email protected]....

> You can then manually put the into the diff view of Github and see what changed.

GitHub throws up 404 when I do this. Same with simply trying to view the old commit directly using the `.../commit/<hash>` link.

In GitLab you can diff the states between force pushes of a branch, which is a feature I love and really miss when working on GitHub.