Frequently, my colleagues will make some changes to an open pull request, rebase their local branch against the base branch - often squashing their changes into previous commits
the old version of the PR
You can do so directly on GitHub: see "Find committer of a force push on GitHub"
Clicking the “force-pushed” link will show a two dot comparison between the two commits.
Original answer: 2016
That would be only available in the reflog of the remote repo, which would include the previous HEAD of the branch force-pushed.
Since the remote repo is a GitHub one, you still can infer the old commit by looking at push events: see "Does github remember commit IDs?".
hat will also show changes that have been introduced into the base branch (typically master)
More exactly, you will always have the differences against a common ancestor (which will include commits from the base branch like master
)
See What are the differences between double-dot ".." and triple-dot "..." in Git diff commit ranges?
So in your case, your forced-pushed branch looks like this on the remote repo:
x--x--x (old branch in reflog)
/
m--M0--M--M (master)
\
X--X--X (new branch forced push)
A diff old_HEAD..newHEAD would include the few M
commits from the base branch, as they are part of the common ancestor (M0
) path.
So you can compare a force-pushed branch (providing you are monitoring pushEvents and know of the previous HEAD of that branch).
But uou cannot easily compare two branches without their common ancestor path.
I believe that this is simply not possible to obtain the old versions of pull requests as suggested by this ticket: https://github.com/isaacs/github/issues/999 Users who post in that repository are advised to contact GitHub support, so likely GitHub support has already replied that it was not possible when that ticket was created.
This is a major missing feature from GitHub pull requests that Gerrit has and which Gerrit users miss badly.
The following works, but is inefficient for large repos because the whole repo worktrees are downloaded:
repo=rossant/awesome-math
a=61e250
b=2b53ad
tmp=$(mktemp -d -p /tmp)
mkdir -p $tmp/{a,b}
curl -SL https://github.com/$repo/archive/$a.tar.gz | tar xz --strip-components=1 -C $tmp/a
curl -SL https://github.com/$repo/archive/$b.tar.gz | tar xz --strip-components=1 -C $tmp/b
git diff --no-index $tmp/{a,b}
rm -r $tmp
This could be much simpler and leaner if Github would allow git fetching revs by their SHA1, but that's not the case yet.
Checkout this answer to another question which want to do something very similar to what you are trying to achieve.
It describe your situation like this:
newcommit -> the new pull request commit
oldcommit -> the old pull request commit
upstream -> the base branch commit the new pull request is based on
Now do this:
git commit-tree newcommit^{tree} -p oldcommit -p upstream -m "message"
git show <commit id returned by previous command>
The idea is that commit-tree will fake a merge between oldcommit
and upstream
producing newcommit
tree and thus containing exactly the code of newcommit
.
It does not modify your current branch at all, it create a new headless commit and give you its ID.
This means git show
will list every modification as a conflict resolution, which is the exact difference between the new PR and the old one.
To be able to do that you need to have the previous PR in your git repository somewhere (if a force push has been performed the git history has been rewritten and can't be recovered unless you have it on your pc or you have access to the server reflog). Check VonC answer for details about this.
Assuming:
master
$BRANCH_NAME
origin/$BRANCH_NAME
You can do like this:
# fetch locally upstream changes (origin/$BRANCH_NAME)
git fetch
# produce the fake merge commit
git commit-tree origin/$BRANCH_NAME^{tree} \
-p $BRANCH_NAME \
-p `git merge-base master origin/$BRANCH_NAME` \
-m "message"
# see "fake" conflict resolution = difference between the two PR
git show <commit id returned by previous command>
the git merge-base
is used to find the common ancestor between two branches, in this case to find the commit on which the new PR is based on in the base branch, if you prefer you can write the commit ID directly.