GitHub pull request showing commits that are already in target branch

Question

I'm trying to review a pull request on GitHub to a branch that isn't master. The target branch was behind master and the pull request showed commits from master, so I merged master and pushed it to GitHub, but the commits and diff for them still appear in the pull request after refreshing. I've doubled checked that the branch on GitHub has the commits from master. Why are they still appearing in the pull request?

I've also checked out the pull request locally and it only shows the un-merged commits.

Mulder

Does this affect the behavior of merging the PR? – Stereoscope

Nope, just the diff on Github. – Mulder

Does anyone know if self-hosted Gitlab suffers the same behavior? – Forereach

I suggest that we all contact GitHub to express our interest in having this behaviour changed (support.github.com/contact). If they don't hear from us then they won't know how important this is and it will be this way forever. – Decennary

Squash-merging can cause this (and requires a rebase). This answer covers how to fix it: https://mcmap.net/q/81535/-how-to-rebase-after-squashing-commits-in-the-original-branch – Tyeshatyg

I just wanna say cheers for wording this question so well. I didn't know it was possible to describe the problem in 11 words.. – Rianna

Can you please upvote here? github.com/orgs/community/discussions/61091 – Nobell

Answer 1

It looks like the Pull Request doesn't keep track of changes to the target branch (I contacted GitHub support, and received a response on 18 Nov 2014 stating this is by design).

However, you can get it to show you the updated changes by doing the following:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Replace githuburl, org, repo, targetbranch, and currentbranch as needed.

Or as hexsprite pointed out in his answer, you can also force it to update by clicking Edit on the PR and temporarily changing the base to a different branch and back again. This produces the warning:

Are you sure you want to change the base?

Some commits from the old base branch may be removed from the timeline, and old review comments may become outdated.

And will leave two log entries in the PR:

Crosse

Yeah, I contacted support a while back and got the same response. They don't optimize for this situation. It is a bit frustrating. Our way of getting around it is to just rebase and force push up, or to close the pull and create a new one. – Mulder

This answer doesn't fix the problem, but just allows the user to see the true diff. – Cantonese

The question was "Why are they still appearing in the pull request?". It answers that question. – Crosse

In our case, compare URL still shows changes already present in target branch. – Grivet

fyi, for others I think this is fixed now. But it depends now on when you create the 2 PRs. If you create PR1 with commits A, B, C, and then start a new branch off that, which then has new commits D, E, then if you create a new PR2, then PR2 will have all the commits, A,B,C,D,E if you haven't merged PR1 yet (and will continue to have all the commits, even after you merge PR1) but will only have commits D,E if you have already merged PR1 when you create PR2. Just fyi, since I had normally created it the second way, and then wondered why the first situation was happening. – Causeuse

@Causeuse The behaviour has not changed, I've just reproduced it. Please see github.com/amillerchip/merge-test/pull/1. Commit 07d3349 "Add more text" is showing up in the PR, even though it exists in the target branch: github.com/amillerchip/merge-test/commits/first_branch however the correct diff can be seen using the compare URL: github.com/amillerchip/merge-test/compare/… – Crosse

Is there a dear-github request to get this changed? – Lavaliere

When using the workaround @hexsprite described above make sure to pick a branch to switch to that has history in common with your current branch otherwise Github will automatically close the PR and will not let you reopen it because "The XX branch has no history in common with YY" – Servo

This question is 6 years old. Has there been any upgrades on the github side, that anyone knows, to change this behavior? This happens when there are several PRs that are descendants of each other and the reviewer hasn't merged any of them yet. Merging them in chronological order does not update the PR diffs of the child branches. – Falter

I'm disappointed that this is unresolved after 6 years. I've opened a ticket with Github Support requesting a status update (Ticket ID: 398652), and I encourage anyone else who hopes to see this resolved to continue doing the same - politely and professionally. It makes me sad to suggest that as someone who's worked in Tech Support but here we are. – Forereach

I rebased the branch with other branch and after that the changes are still being shown when opening another PR. Anyone? – Misrule

How do i navigate to this ticket 398652 ? – Arneson

Answer 2

Here's a good workaround. Use the Edit button when viewing the PR in GitHub to change the base branch to something other than master. Then switch it back to master and it will now correctly show only the changes from the most recent commits.

De

I'm surprised more people don't acknowledge this solution. I suspect the original out of date pull request would be just fine, but I didn't like the GitHub shows all the out of date files, so I used this and it both keeps the commentary and only shows the actual changes about to be merged. Thanks! – Sigfried

This doesn't seem to work for me, it just adds the info that I changed the base branch to something else and then back to master. cfr: github.com/europeana/search/pull/30 – Stan

For what it's worth, I checked this solution again just now, and it still works. Calvin's problem is that the target repo is squashing his PR, so the commit that gets added to the target repo is different to the one in his. He should be resetting his master branch each time, rather than merging in their upstream squashed commits, effectively duplicating all the commits. – Crosse

I added a comment to that PR with more details. – Crosse

Thanks, this worked for me. Ideally Github should do that automatically , or should provide an update option as done on Azure Devops SCM – Transudation

Any idea if this would become automatic on Github's end? Seems like a nice feature, but this solution definitely worked – Belike

This worked for me with Gitlab. Edited MR > Changed Branch to Merge to > Save > Edit > Changed Branch to Merge to back to Master > Save > Profit. – Nichani

This doesn't work for me. I end up back in the same position is started. – Bacchus

This has not worked to me, I have checked that the commit was effectivelly merged into the base branch (which is not master) but the commits is still in the Commits tab, although their changes are not displayed in the Files Changed tab, since it was already merged. – Frenchpolish

Best one so far! – Harlene

Didn't work for me on a direct PR branch>master (no rebases). They might have "fixed" this. Very silly that you have to go through these hoops for something so basic. – Tarry

I confirm that this is still the behavior to this day. If that's working as intended (i.e. to "freeze" the state of the branch as of the time the PR is opened), Github should add the option to refresh it without that "Edit" workaround, which is the default behavior in Gitlab. For those who say the workaround doesn't do it for them: make sure the commits hashes are the same; sometimes a commit hash can be changed in some merging scenarios, and that could make it so the difftool doesn't compare correctly -- which I would expect and probably want it to, anyways. – Mosa

For what it's worth this solution still works, but you may have to apply @AdamMillerchip 's solution that he added as comment to the mentioned repo above. For history, you may have to something like git checkout -B main origin/main before your next PR and then run the steps above. Quite a relief to no longer have "run-away git commits"! – Diadromous

For me, it sometimes works and sometime not! – Gymnosophist

This didn't work for me. – Silverware

Answer 3

To sum up, GitHub does not rebase the commit history automatically in pull requests. The simplest solutions are:

Solution 1: Rebase

Suppose that you want to merge into master from feature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force-with-lease

If you are working on a fork then you might need to replace origin above with upstream. See How do I update a GitHub forked repository? to learn more about tracking remote branches of the original repository.

Solution 2: Create a new pull request

Suppose that you want to merge intro master from feature-01:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

Now open a pull request for feature-01-rebased and close the one for feature-01.

Powe

A rebase changes the commit hashes, so would it end up trashing the existing review comments? – Beutler

@Beutler Probably yes. – Powe

Anything to watch out for when doing push --force? – Steeple

@Beutler that's not my experience. I frequently rebase mid-review and comments aren't lost. Though I do lose the history of changes in the PR – Moxa

@JoelBerkeley I actually experienced a couple of reviews meanwhile in which the author rebased and observed that the comments are in tact. However, we lose the ability to review incrementally and for large reviews it is a huge penalty on the reviewers. We now have a few guidelines for our PRs and one of those is never to rebase after the review is open (unless one is sure that nobody started reviewing yet). Merging is fine but our guideline is to not mix the merge change with any other changes other than the conflict resolutions. – Beutler

regarding things to watch out for when doing --force, watch out that other commits from someone else are not on that branch (the remote branch) as you will likely end up removing them if you don't have those same commits locally. --force-with-lease is safer in the case that multiple people are commiting to the same feature branch – Massie

Or instead of --force use --force-with-lease as I think this will bail out safely if someone has altered your branch in the repo. – Familiarize

This looks like the correct (and cleanest) answer to me, +1. – Sapienza

Wow! I had PR with so many files not commited by myself, and trying to revert it never worked... until I found your magic. Thanks!! – Lib

I had correct parent commit hash and still foreign commits in my PR - git push --force-with-lease did the trick for me - thanks! – Assent

Solution 2 worked great for me. – Whim

Answer 4

This happens with GitHub when you squash commits merged in from the target branch.

I had been using squash and merge with Github as the default merge strategy, including merges from the target branch. This introduces a new commit and GitHub doesn't recognize that this squashed commit is the same as the ones already in master (but with different hashes). Git handles it properly but you see all the changes again in GitHub, making it annoying to review. The solution is to do a regular merge of these pulled in upstream commits instead of a squash and merge. When you want to merge in another branch into yours as a dependency, git merge --squash and revert that single commit before pulling from master once that other branch has actually made it to master.

EDIT: another solution is to rebase and force push. Clean but rewritten history

Enamor

Thanks @achille, this was really the issue on my side. After disabling the squash merge it is resolved. – Gimcrackery

Github Rebase Merge will also cause this issue – Glosseme

Another solution with this is to cherry-pick the desired commits to a new branch that is based on main. If you rebased your commits on the merged branch this way should be quite easy and efficient. – Phrenology

Answer 5

For anyone else coming across this and confused by GitHub Pull Request behavior, the root cause is that a PR is a diff of the source branch tip against the common ancestor of the source branch and the target branch. It will therefore show all changes on the source branch up to the common ancestor and will not take into account any changes that may have occurred on the target branch.

More information available here: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Common ancestor based diffs seem dangerous. I wish GitHub had an option to make a more standard 3-way merge-based PR.

EDIT - I never did mention the obvious workaround I always use to avoid any issues arising from this. Just merge your target branch into your PR branch regularly and you will not run into any unpleasant surprises.

Outrider

The reason you mentioned seems correct, but I am confused because generally whenever the master gets updated, i back-merge the changes to my branch ... git checkout my-branch -> git merge master. The pull request gets refreshed immediately. Does the common ancestor also get updated? – Midst

This behavior seems to occur when doing rebase instead of merge – Midst

@G.One, really late reply, but yes – if you merge from that master branch to your source branch, you've by definition updated the common ancestor. It's the commit on master you merged from. – Outrider

If this is true, why does the workaround of changing the target branch and then changing it back work? That doesn't change the common ancestor. – Coincident

To answer my own question from a few minutes ago: it's because the common ancestor is only recalculated when the PR is opened or when the target branch is changed. See here. So if the workaround helps, for example if the same commits are merged into both the source and target branches, the problem isn't with the common ancestor method itself, rather the fact that it isn't recalculated. – Coincident

switching target branch doesn't work for me... – Gonfanon

Answer 6

You need to add the following to your ~/.gitconfig file:

[rebase]
    autosquash = true

This will automatically achieve the same as what this answer shows.

I got this from here.

Truck

@RonaldRey git rebasing is not a universal solution, because it involves editing the history. If everybody is working on private forks that are never cloned by others, then it's fine, but as soon as somebody clones your repository and you then edit the history, you end up with different histories. – Crosse

Answer 7

One way to fix this is to git rebase targetbranch in that PR. Then git push --force targetbranch, then Github will show the right commits and diff. Be careful with this if you don't know what you are doing. Maybe checkout a test branch first to do the rebase then git diff targetbranch to make sure it is still what you want.

Deppy

Or instead of --force use --force-with-lease as I think this will bail out safely if someone has altered your branch in the repo. – Familiarize

Answer 8

Instead of the 3-dot url use 2-dot url to compare

Instead of

http://githuburl/org/repo/compare/targetbranch...currentbranch

Use

http://githuburl/org/repo/compare/targetbranch..currentbranch

Croatian

this shows the correct diff, but cancels the PR – Leotie

Answer 9

What I tried and why it's happening?

None of the solutions worked for me. When I used two dots i.e. .. instead of ... the diff on GH was much closer to what I changed. But still not exactly all my changes.

This happens because a problem in how GitHub shows squash merged changes. Best explained here

It basically happens if:

1. Push up changes of featureBranch
2. Squash merge it into main
3. Locally while I'm still on featureBranch I merge it with main. Make more changes and push it up again.
4. But then on GitHub I see more changes than I expect.

It's worth noting that this isn't a git problem. Instead it's a GitHub problem. GitHub can't tell that the squashed commit is identical the sum of the non-squash commits and causes an extra diff.

---

Solution

On your local main, undo and stash all changes that haven't been merged with main. To do that I did. Example if I had 4 commits that weren't in my PR that got squash merged then I'd do:

• git reset HEAD~4
• git stash save "last 4 commits"

Then create a new branch with what you've just stashed. Steps:

• git checkout main
• git checkout -b newBranch
• git stash apply
• git add --all
• git commit -m "some message"
• git push

Sarene

Answer 10

This happens when PRs are getting merged by Squash and merge option. If you want old commits not to be displayed in the following PRs, then simply merge the PRs with Create a merge commit option.

• Create a merge commit
• Squash and merge
• Rebase and merge

Note: Once this is done, the next PRs are always show their own commits and not old ones, because old ones are already added to base branch by Create a merge commit option.

Technical explanations: What is the difference between merge --squash and rebase?

Nickelsen

Answer 11

The issue is not happening for me once i started doing the following before starting a new change or creating a PR.

git pull --rebase origin <target-branch>

This basically ensures that whatever new changes are added from the local is stacked on top of what is there currently in the remote branch. Hence our local branch is always on top of the current remote head and only the new commits are there in the PR.

Julianjuliana

Answer 12

A lazy way of resolving this issue: Manually edit the file in your branch that is already in the target branch, with the same code copied from the file of the target branch, and save it.. it gets committed. The PR would now be updated automatically with the new commit you made, resolving the issue.

Dyslalia

Answer 13

I'm not exactly sure about the theory behind this. But I got this several times and able to fix this by doing the following.

git pull --rebase

This will fetch and merge the changes from your original repo master branch (If you have point to that)

Then you push your changes forcefully to your github cloned repository (target)

git push -f origin master

This will make sure your github clone and the your parent repo are at the same github commit level and you don't see any unnecessary changes across branches.

Cogitation

For me I had to git rebase origin/master (Windows 10 user here). Resolve merge conflicts, and after that the pull requests only showed the recently added changes. – Wive

Answer 14

Using git cherry-pick

If the rebase process gets to tangled up for you as it did for me, another option is to use git cherry-pick. These are the steps:

• Update your local target branch using git pull.
• checkout the branch where you made changes and copy the commit IDs of the commits you want. if the branch name is tangled, do git checkout tangled and then git log. You can scroll through the git log output using the up/down arrows on the keyboard. The commit IDs are the long numbers that each commit contains.
• Create a new branch from your target branch (e.g main) using git checkout -b new-branch-name when you are on the target branch.
• On the new branch, do git cherry-pick commit-id where commit-id is the long number that you copied from git log which identifies the commit you want to push. You can do this multiple times, changing the id each time to get another commit.
• If you run git log on this new branch which you created, you can see that only the changes you have added exist after your target branch's head, as expected.
• Lastly, push the changes to remote using git push origin new-branch-name and create a pull request.

Sheikdom

Answer 15

Story to my problem before I answer:

I'll consider 3 branches, master, testing, feature.

testing branch would already have master changes.

The problem arises for me when I merge master into my feature branch, then work and commit into my feature branch and when I raise a PR against testing, it shows changes that are already in testing again. This is frustrating and my colleagues don't face this issue because they use command prompt. And I do not wish to use command prompt.

I use GitHub Desktop app and this happens to me more than often and I couldn't do anything about it until today.

If you have countable commits (4-5 max) on your feature branch, only then this procedure would be useful. You may get confused if there are a lot of commits.

Now the work around for GitHub Desktop Users:

1. Create a branch from testing name it "feature-merge-to-testing"
2. Cherry-pick those commits onto "feature-merge-to-testing".
3. Resolve conflicts.
4. Raise a PR now against the testing branch.
5. Delete the "feature-merge-to-testing" branch once done.

Until GitHub fixes the issue with PRs in Desktop application. I think I'm gonna follow this procedure, which seems to work for me. Let me know if there is any effective work around.

And that changing the base(the first answer to this question), didn't work for me.

Lincolnlincolnshire

Answer 16

I hit this after creating a PR for a fix into another development branch. After noticing the changes I hadn't made in the PR, I merged out from main into both branches. That didn't help. But, the extra changes disappeared after I merged the destination branch into my branch.

git checkout <fix branch>
git merge <destination brach>
git commit -a
git push

Before doing this, I saved a copy of my source branch. Its commit history shows only one of the merges: Merge branch 'main' into <fix branch>. After merging as above, a new commit precedes this one in the history Merge branch 'main' into <destination branch>.

The commit introduced by the merge out from destination (above) shows no changes. Also, before merging, diffs between the branches weren't showing changes that the PR was including.

Before the new merge from destination, it appears the PR was failing to reflect changes introduced to the destination branch after the PR had been opened. For me, merging out from the destination branch reset things to the expected state.

Lateritious

Answer 17

In my case, it was happening due to latest pull request in the current branch. And none of the above solutions worked.

Steps I followed:

1. So, I checkout to my earlier commit:

   git checkout sha

2. It creates a detached HEAD. So, create a new branch out of this commit by

   git branch new-branch

3. I pushed this to the upstream repo:

   git push upstream new-branch

4. Created a PR again from new-branch to target-branch.

5. And it should me the correct changes this time.

Confide

Answer 18

There is an option "Always suggest updating pull request branches" in the github project settings that I think will solve this:

Soke

Answer 19

I found a way to get the right behavior (tested in November 2020).

After git merge and resolving conflicts need to use git merge --continue instead of git commit ....

Rhythmical

Answer 20

Try the following:

1. Delete the local folder with the project
2. git clone the project again

This should resolve the issue when you create a new PR.

Hydrogenate

Thank you for your interest in contributing to the Stack Overflow community. This question already has quite a few answers—including one that has been extensively validated by the community. Are you certain your approach hasn’t been given previously? If so, it would be useful to explain how your approach is different, under what circumstances your approach might be preferred, and/or why you think the previous answers aren’t sufficient. Can you kindly edit your answer to offer an explanation? – Gratin

Answer 21

Fail safe approach if you are too worried about messing things up: go to the file and manually remove the changes, then squash with your last commit using

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

I there are no conflicts, you are good to go!

Pacificia