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.

[PatrickNercessian]

Thank you! This works and saves so much headache

[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
💔 🙏

[SultanDino]

Adding my voice to this.
This is the second issue our team is facing and it makes code review a nightmare.
At this point we are considering switching to another system.

[ounjoseph]

Hey GitHub, is there any planned fix for this issue

[t0astt]

Joining in the conversation here - this is an extreme annoyance. It makes a normal, sane branching strategy extremely cumbersome. Diffing branches locally shows zero differences, however the PR I open in GitHub shows craziness. Please fix or we'll consider moving over to GitLab.

[BrinkmeyW]

Some time ago I opened a support ticket for this and received a pretty unhelpful answer (see below). At least they seem aware about the issue, but as to plans in changing this ..... I don't know could be a while. I would suggest anyone who is annoyed to also open a ticket, maybe it gets solved faster if more people complain.

Message from GitHub- Support

Thank you for reaching out with your concerns, and I understand how frustrating this situation can be.

When you merge a pull request using either the squash or rebase options on GitHub, it creates new commit(s) in the base branch. However, the original commits still exist in your source branch. This is why your source branch appears "outdated" after such merges because the exact commits don't match between the branches, even though the content might.

For branches that you plan to keep using after merging i.e long-running branches, a merge commit might be more suitable despite its tendency to clutter history. This method preserves the exact commit history and can help avoid the branch being flagged as outdated.

The behavior you're experiencing with rebase and merge is indeed different from a traditional git rebase command. We mention this here: Rebasing and merging your commits

Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

We do not have a true fast-forward merge option available on GitHub. An alternative workflow to workaround this limitation could be to create a PR, make sure all checks and other requirements pass on GitHub, perform a fast-forward merge locally via the command line, and then pushing the changes back to the remote branch. This approach keeps your branches in sync without additional force-pushes.

We're aware of the community's requests for more flexibility in merge options, including fast-forward merges directly within GitHub. I've forwarded your feedback to our product team for consideration. While our roadmap isn't public, we regularly update the GitHub Blog with new features and updates. We also encourage you to share any further thoughts or details through our feedback form. Our product team monitors these discussions closely to understand user needs better.

If you have any more questions or need further clarification, please feel free to reach out.

Regards,
Rocky

[katannshaw]

I thought I was all alone and doing something wrong, but then I found this post. This has driven me mad. The "Delete and recreate PR 2 (feature-branch-2) after PR 1 (feature-branch-1) is merged" workaround is the only thing I've found that works to clean up the commits, but it's a pain, especially when you want to get things done quickly.

[t0astt]

Agreed. My team doesn't have any particularly strong lock-in to GitHub yet, so I'm considering trialling GitLab to see if they handle this better.

[katannshaw]

@t0astt I worked with GitLab a few years back and liked it. They both have their advantages and disadvantages like all tech. I don't have the choice to change it up, as it's up to each customer in my case. But please post back on what you find as it would be interesting to know for my private work.

[shahkaush]

I came across this issue today. Many files are showing changes which are already in the main branch. I would not want those files touched unnecessarily. The PR should only show the changes w.r.t. the branch to be merged into (in my case the main branch). As some other user commented earlier, this functionality should be the essence of the product. @github Please support and resolve.

[flow96]

We have the same issue, PRs show changes that are already on the target branch. I really don't know what Github uses to compare branches in Pull Requests but it's completely wrong.
The fact that the key feature of this product has a major bug and this is not getting any attention by github is crazy.
@github please adress this issue!

[EliveltonRepolho]

Hey Github, are you seeing community messages ? What is the plan to resolve it ?

[ltutar]

I stopped using squash and rebase to avoid this issue. The downside is that I have all the commit messages of a feature also in the main branch. But still better than having these awful merge conflicts especially with SQL statements. I wasn't expecting this issue to be open so long with GitHub actually.

[laskmat]

bump - but seems they don't care. Btw GitLab got same issue

[mikeweilgart]

I used fast forward merges with GitLab for years and never ran into this problem, as I recall the merge requests always updated sanely and showed me exactly the same as what I got on the command line. Could you please share a link to the GitLab issue about this, if I'm really mistaken and they have the same problem?

[remiguittaut]

I can confirm what @mikeweilgart wrote. ff-only works perfectly on gitlab.

[posthardcode]

+1 on that confirmation; it's pretty wild that GitHub doesn't support this 😳

[karlmacklin]

Why is this a thing?
We went from bitbucket to github thinking it would be a better experience. Now we're forced to edit every PR we look at to update the base branch to something else then back.
Would be nice with a button at least, it could be labeled "rethink what this PR actually does so it doesn't play tricks on the reviewer, and finally show the truth".

[alepev]

Still having this problem!

[duraib]

This is terribly cumbersome every time when we see all the commits as not merged but shows 0 file changes.

[briemarie]

Also having this problem still! It occurs if I simply push my branch, but also if I rebase first. Trying to rebase against main before pushing my branch shows only the commit I want, but the PR still opens with a bunch of commits that are already on main. Same exact behavior whether I rebase or not.

Some additional context. When I checkout main it tells me that Your branch is ahead of 'origin/main' by 4 commits. But when I git pull origin main it says everything is up to date.

[briemarie]

I at least temporarily solved this by hard resetting main to the last commit that is in GitHub and then rebased my branch against that.

[BrinkmeyW]

It is really very disappointing that Github is not reacting..... Like I already said last year maybe try and write the support....really pester them with mails and tickets and who knows maybe this will help