Comparing commits after rebasing

[percysnoodle]

Select Topic Area

Product Feedback

Body

In our workflow for pull requests, we quite often have a situation where:

• the reviewer will request some changes
• the engineer who raised the PR will force-push a new commit including those changes
• the reviewer will compare the old and new commits to confirm that the requested changes have been made.

GitHub recently added a "Compare" button in the PR history which makes this very easy. That's brilliant - thank you so much for adding this!

Sometimes, we run into a similar situation, where:

• the reviewer will request some changes
• the engineer who raised the PR will make those changes
• tests fail due to a flaky spec which has already been fixed in main
• the engineer rebases onto main then force-pushes
• the reviewer will compare the old and new commits, but the requested changes are lost in the noise of the rebase

In this situation, what we need is to compare not the end-state of the old and new commits, but rather the changes made in the old and new commits, so that the reviewer can confirm that they differ in the requested way.

The git CLI provides a tool called range-diff which makes this possible (though hardly easy). Would it be possible to provide something in the GitHub UI which would allow us to make these comparisons?

[ian-h-chamberlain]

Related: https://github.com/orgs/community/discussions/3478 particularly comment https://github.com/orgs/community/discussions/3478#discussioncomment-3697339

[EugenKon]

I use this a couple of years already, but in console. For this purpose I created next aliases:

    # When we fetch changes some branch maybe force rebased.
    # The changes will be shouwn as: abcdef...1a2bc3
    # To see what happened after rebasing to forced update
    fullchanges = log --graph --decorate --pretty=oneline --abbrev-commit --cherry-mark --boundary --left-right
    changes     = log --graph --decorate --pretty=oneline --abbrev-commit --cherry-pick --boundary --left-right

    # right-only means: the patches that was added by right side
    ltheirs     = log --graph --decorate --pretty=oneline --abbrev-commit --cherry-pick --boundary --left-right --right-only

    # left-only means: the patches that was added by left side
    lmine       = log --graph --decorate --pretty=oneline --abbrev-commit --cherry-pick --boundary --left-right --left-only

When I run git fullchanges sha1...sha2 I can see which commits are differ:

Or git changes sha1...sha2. In compare to previous command we will see only changed commits:

I also asked git team to implement git range-diff --by-tittle to not just compare a range of commits, but also compare commit's titles. Otherwise git range-diff could compare not related commits.

Hope this helps.

[koffes]

I would be very interested in seeing a solution for this as well.
Developer:
Submit a PR -> gets feedback -> rebases -> pushes -> makes changes -> pushes : All is fine. It is however easy to:
Submit a PR -> gets feedback -> rebases -> makes changes -> pushes : The "compare" includes a lot of noise.

Could we have some tooling which compares the latest push with the target branch. All changes which are in the target branch are greyed out/marked in some way?

[koffes]

This would be a huge workflow improvement Github-wide for all languages.

[alexsven]

I second this!

[RalfJung]

This is the single most painful thing about Github right now. I don't even know how much time I am spending teaching every single contributor about git rebase --interactive --keep-base, just to work around this issue when they are e.g. squashing commits. But sometimes rebases are actually necessary, and then I have to basically re-review the entire PR. The productivity boost we could get by Github having better support for force-pushes and rebases is enormous.

The "compare" link is also far from ideal: there can be many force-pushes between my last review and now. Github will show a compare link for some of them (but not all, a bunch of adjacent force pushes get collapsed so that only the last one has a "compare link"), but I still have to look at all of them separately. What would be ideal is a button next to my review that says "compare with current version" and that covers all force-pushes since that review.