Pull request showing commits that have already been merged (via fast-forward merge)

[flakey-bit]

Select Topic Area

Bug

Body

Using GitHub enterprise, I have the following situation:

• master is at SHA deadbeef
• feature/branch1 is 3x commits ahead of master (fast-forward mergable into master)
• feature/branch2 is 2x commits ahead of feature/branch1 (fast-forward mergable into both master and feature/branch1)

I open up a couple of PRs:

• PR to merge feature/branch1 into master (PR 1)
• PR to merge feature/branch2 into master (PR 2)

Initially, PR 2 shows the commits from both feature/branch1 & feature/branch2 - this is expected (total of 5 commits on the PR). However when I merge PR 1 (by way of fast-forward merge), the commit list in PR 2 continues to show all 5 commits (including the 3 that have already been merged).

Expected behvaiour is for PR 2 to update and only show the (2x) commits that have not yet been merged into master yet. Note that if I create a brand new PR (merging feature/branch2 into master) then it only shows the 2x commits.

[flakey-bit]

As a workaround you can change the base branch for the PR to some other branch and then back to master again.

[mardough]

when i changed the base branch to a branch other than master, it successfully only shows the commits that i want to merge, however, immediately changing the base branch back to master, all the old commits return

[KristianI]

Did anyone find a more permanent fix for this? I am experiencing old diffs all the time, it is really a hassle.

[malaville]

Same here we're experiencing the same issue

[danielnorberg]

Seeing this lately here as well, but on github.com, not Github Enterprise.

[alanrichards86]

Im seeing this as well on github.com. Driving me nuts.

[paulboeck]

I'm seeing the same behavior on github.com. It's so hard to then tell what changes are 'actually' to be reviewed and merged in the PR. I tried the switch-the-base-branch work around, but to no avail.

[sporty81]

To me, this is a major bug and flaw in GitHub. The whole reason we use PRs is to understand what has changed and review them. We can't trust the most basic functionality of the product. This is ridiculous.

[andres-echo]

I ran into this today for the first time and thought I was taking crazy pills:

• Merged a PR two weeks ago with various changes from dev-branch into main
• Open fresh PR from dev-branch to continue onto new work expecting the usual 0 changes in the PR to be shown
• Instead I see the changes from the last PR as if they were never merged in. The files on main have all of the changes from the PR clear as day, yet the new PR diff view between main and dev-branch shows the changes as if the current files on main are in a different state (pre my PR from two weeks ago).
• Changing the target branch from main to another branch did not work - when I change back to main, the "changes" reappear.

I was getting ready to pile onto this issue, HOWEVER I noticed one key thing that I usually do that I forgot to do in this case, which I will share in case anyone is dense like me. After merging my last PR, I forgot to pull main back into dev-branch (ie, while on dev-branch, git pull origin main & git push). Sanity was restored after doing this and the PR updated to show no changes.

[ethan-rio]

I'm experiencing the same issue as well. Has anyone got a solution for this?

[mimenezes]

Normally, in this case I delete my pull request and create it again from the same branch which then shows only my changes.

[The-Anton]

I not sure but for me rebasing the feature branch from main branch solves this issues.

[ethan-rio]

I've found a solution for this. So apparently, I've been squash commits merged in from the target branch, and this creates a new commit and interestingly GH doesn't recognise that this commit is already in.

So I have to rebase and force push, and just have to keep in mind not to squash commits before merging. Hope this helps.

[ceotrammell]

I've found a solution for this. So apparently, I've been squash commits merged in from the target branch, and this creates a new commit and interestingly GH doesn't recognise that this commit is already in.

So I have to rebase and force push, and just have to keep in mind not to squash commits before merging. Hope this helps.

Yeah... I've been doing the same lol

[AyushSehrawat]

I do the same, squash and merge dev to main. But i want to keep doing it, so my only option is rebasing and force push ?

[BrinkmeyW]

I have the same problem. When I choose the 'rebase and merge' option the commit hashes change and even though I just merged dev to main, dev is behind again because of the changed commit hashes.

This is so annoying and the only solution is to rebase and force push everytime?!

There is a discussion on stackoverflow about this issue (https://stackoverflow.com/questions/68878506/github-rebase-merge-creates-new-commit-hashes).

There are 3 options to merge.

1. With 'merge commit' - which I hate because it clutters the whole history with merge-commit messages.
2. With 'Squash' which I don't use because I usually have squashed the commits that I want squashed on the feature-branch already. So if I have seperate commits I want to keep them as they are.
3. Last option is 'Rebase and Merge' which as described changes the hashes.

Why is there no option for a fast-forward merge? Why always rebase even if there are no conflicts? If I need to rebase and force-push all the time why even have PRs at all? Additionally every force push triggers an additional build that I do not need, that is time consuming and takes resources. So I usually cancel the build, but this also means that I have an alleged 'failed' build for the branch.

Is there really no way to solve this?

[ilanKeshet]

Hey GitHub, Any timeline for an actual resolution, making this issue go away for good?

This is a constant annoyance, for a few reasons:

1. Auto addition of code owners to PRs harm reviewers
2. Manual toil, confusion and having to explain GitHub bugs harms reviewees
3. Bloated and misleading auto-generated merge squash messages pollute git history

Please make it better, we really want to love GitHub but this issue is really making it hard for us
💔 🙏