GitHub Community
Pull Request Diffs Do Not Update After Changes Are Made #16351
Replies: 23 comments 49 replies
|
pull request diffs seem to be using a 3 dot diff instead of a 2 dot diff ( 2 dot diff against the current head of the target branch is what it should be doing.) its dangerous and it makes the github pull request/ review screen completely useless. they need to fix it. |
No, no and no. It should do a 2-dot diff between target branch and merge result. Which is essentially what a 3-dot diff emulates, sometimes well, sometimes poorly. |
|
@numberZero a 3 dot diff wont show you the difference against the head of the target branch, only the changes since the branch was made, and that's the problem here. |
|
Yeah I'm seeing the same thing here. Open the PR, make changes, and the PR |
|
Do you happen to know whether this has been classified as a bug and is tracked somehow? I couldn't find it... |
|
I am also facing this issue , even I removed the changes and added them again with new commits , still it's not detecting them. |
|
Yeah, this is making reviews more difficult than they need to be. Would love for this to be addressed |
|
Yeah, I see the need to understand what the PR introduced, but would be great to have a checkbox to be able to easily compare with the latest commit from the base branch. I wonder if this is possible in any near future. |
|
for me this decision makes no sense at all. a PR is clearly a compare and merge against a target 'branch', PR's are not about the changes on a single branch - you can see that info anywhere. |
|
Ran into this today, having worked with Gitlab for the last couple of years this really confuses me. From my experience the Gitlab UI updates Merge Request automatically whenever the base branch is updated. In this process commits that have been merged in the mean time are left out of the view and only the code changes 'at present' are displayed. Not sure if both these differences are represented just in the diffing methods used, but I suppose Github favours 3 dot diffs whereas GitLab favors 2 dot diffs. |
|
2-dot comparison between base and topic branches makes no sense at all. It would show lines removed from the base branch as additions which is clearly wrong, the actual merge won’t readd them. 3-dot comparison is better as it shows the changes to be merged. But there is a third option: 2-dot comparison between base branch and merge result. I.e. the changes that would actually be introduced by the PR. But it is way more expensive to compute as it requires actually performing the merge just to show the diff, and may also fail if there are conflicts. Also, what the OP describes sounds more like a bug than 2-or-3-dot choice. Something along the lines of https://github.com/orgs/community/discussions/51948. |
Yes, this please |
|
This is a shock to our development team migrating from bitbucket recently. Any workaround I can implement to show diff from target branch and not all the changes done since last common commit? I want to see the changes a PR will do |
|
Well I did find a way to compare the branches in 2 dot comparison ( by default it's in 3 dot when a PR is created ), not sure it might help your case but it might give you another depth in the changes between the 2 branches.
change the 3 dots to 2 dots and you'll start viewing it in 2 dot comparison
|
|
You sir are a hero to many. |
|
I've noticed this a while ago and couldn't figure out the cause. Sometimes a PR also shows conflicts but when I did the manual merge there's none. Also sometimes when we update the base branch of PR in hope of resolving the conflicts, the PR page still shows the same conflicts even though in fact the conflicts have been resolved due to the latest commit made into the base branch. |
|
I tested a few times, sometimes even with manually changing to the two dot diff in the URL while doing a code comparison between two branches, I don't get the actual changes showing correctly. |
|
This is happening to me today -- PRs are not updating after pushing to the branch |
|
+1 |
|
they seem to have acknowledged the issue: https://www.githubstatus.com/incidents/pr0ptqcw6q8d |
|
Changing base branch to something different and then back to the original fixed the problem for me - now all commits can be seen in the PR. |
|
on the issue description they say that simply making a new commit to the branch is enough to fix the PR. |
|
+1 |
|
seems like this is a nice workaround: https://github.com/orgs/community/discussions/16351#discussioncomment-6327770
[wanted to make the solution easily visible 😄] |
|
this hasn't worked for me for a very long time. It did work years ago. |
|
Just ran into this for the first time, and this fixed the view in the PR for me. Thanks! |
|
yeah, sadly it does not work in case of a newly created PR :( |
|
Also I think the actions are not being run on the missing commits even after changing the base branches... It's a major issue. |
|
It's still an issue, diff is strange, merge conflicts, etc. |
|
Coming from Azure Devops this makes no sense to me.. I get that some people might prefer it so make it an option against the repository? |
|
this is how devops works too by default, although it looks like there's an option to at least force it to update. |
|
It seems you're experiencing a problem with GitHub's pull request (PR) interface not displaying the correct changes after a requested change has been made. This can be frustrating, especially when trying to verify changes without leaving GitHub. To address this: Clear Browser Cache: Sometimes, caching issues can cause discrepancies in the displayed content. Try clearing your browser cache and refreshing the PR page. Hard Refresh: Use a hard refresh (usually Ctrl + F5 or Shift + Ctrl + R) to force your browser to fetch the latest content. Review Comments: Make sure the PR author has properly addressed your comments. Review the PR discussion to confirm that the requested changes were indeed made. Use GitHub's "Review Changes" Feature: Instead of relying solely on viewing individual files, use GitHub's "Review Changes" feature. It displays all changes in the PR at once, making it easier to verify changes. Compare View: In the PR, click on the "Files changed" tab and then click "Review changes." This view should show you all the changes made in response to your comments. Diff URL: Manually check the diff URL in the address bar. It should include the commit hash of the latest changes. For example: https://github.com/user/repo/pull/123/files?diff=split#commit-hash. Logged Out: Sometimes, staying logged out of GitHub and then logging back in can help resolve display issues. Check GitHub Status: Occasionally, GitHub may experience service disruptions. Check the GitHub Status page to ensure there are no ongoing issues. Contact GitHub Support: If the problem persists, you can reach out to GitHub Support for assistance. Use the GitHub Support platform to report the issue. Stay Updated: Keep an eye on the discussion in the GitHub issue you mentioned. Others might share solutions or workarounds if they've experienced the same problem. Remember, while waiting for a resolution, you can continue using the workaround of pulling down the branch to verify changes if needed. |
|
this isn't a refresh/browser cache issue. |
|
hmmm, why does this answer sound exactly like an AI-generated one? 🤔 |
|
sorry for my misunderstanding |
|
Sharing my experience here, as it's hard to find information on this issue, and it's really bother me I am maintaining a declarative dependency management tool to automate file update https://github.com/updatecli/updatecli/ For various reason, Updatecli will often reuse the same temporary branch so we automatically delete them when a pull request is merged. It took us a few weeks back then to recover from it, and since then we randomly see wrong "diff" information like from an old branch which is supposed to be have been delete since then. An example here civo/kubernetes-marketplace#545 (comment) Usually we just close the pull request, delete the branch, and let Updatecli recreate everything correctly but ideally I would like to find a solution |
|
Why github is so stubron on basic functionalities? The same goes with fast-forward merges. So baSIC! |
|
Faced this today and the only thing that worked for me is to create a fresh PR, merge my previous PR into it to get the correct diff against main |
|
I've been having this issue for months. Re-selecting the base branch (ie. main) for a PR usually forces it to update the file changes diff. Edit: I contacted github support and they said it's a known quirk and they have an open issue to fix it in a future release. |
|
thanks for the trick, this has been bother me for years |
Because github is trash, apparently. This is, indeed basic functionality, and if it can't get this right why should I trust it to do anything? |
|
It's a Microsoft thing. Azure Devops has exactly the same problem, by design. |
|
Being an ADO user daily for >6 years, I can say I have NEVER seen anything like a PR "lag" on showing updates. |
|
This discussion isn't about any kind of lag, it's about pull requests comparing the PR feature branch head with the commit on the target branch from where the PR branch was created - this is NOT how PR's should work. A PR SHOULD compare the head of both the feature and target branches, but by design both github and devops don't work like this, and the only fix is to rebase your feature branch and push again. |
|
Technically the OP is talking about a comment on a PR "perma-linked" to the original code, not the updated code in response to the comment, in the feature branch. Which is still an issue, different from not showing commits on target OR feature at all. ADO works great in this regard, in that the default behavior is to show the latest code @ the line the comment is attached, but there's a btn that shows and allows you to "see comment in the original context." Super easy to review and make sure changes from review feedback are complete. My issue with GH that led me here was that new commits on a feature branch were not showing in the pr, though I could see them on the branch itself. Possibly, I noticed the leading edge of some service interruptions GH had this week, since the commits eventually did show up in the PR and the diffs (15-30 minutes or more)? As far as rebasing the feature branch or otherwise syncing with the original branch, I haven't noticed the issue often on ADO, likely because my SOP is to rebase/sync a feature branch before opening a PR, mainly to resolve conflicts. From there, yes, ADO will at least show when the target has updated, and usually auto-re-merge, I think, but at least you get a button right @ the top of the PR to re-start the merge in the latest version. It may be dependent on policies, like if there's a policy-build/pipeline may auto-remerge on feature-branch update. |
|
I closed and reopened the PR, and then the diff on GitHub worked properly. |
|
Wondering if this will be addressed at some point since it can easily lead to unwanted behaviour / wrong code reviews.. |
|
Also just discovered this issue after 5 years of using GitHub professionally. I was wondering why I was not seeing the right diff after the target branch updated and a Google search led me here. I didn't even notice before, as it's a silent error. I thought that what I was always seeing was "Files changed" between the target branch and incoming branch, so I never questioned it until it became very obvious in my latest PR. It is absolutely not expected behaviour for it to be anything else. And yet it is. Are GitHub ever going to address this really poor user experience? |
|
agreed, it's ridiculous that such a basic functionality is broken for years... |
|
Bitbucket had a correct diff showing before their "performance improvement" in 2022 that intentionally dropped the "3-way" diff we all here want https://www.atlassian.com/blog/bitbucket/improving-performance-on-complex-diffs There was a comment somewhere from the maintainer of that feature that it became too hard to maintain this feature effort-wise, as it was conflicting with other Bitbucket features (which could be a similar cause for GitHub), but I can't find their comment anymore (maybe it was removed/hidden/redacted). That has become a huge pain for anyone who does not want to follow a rigid gitflow or trunk-based development (i.e. can't simply rebase/pull target branch into the source branch without creating more temporary branches). And I suppose it was always the case for GitHub in particular? |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
When I comment on a PR requesting a change and the change is made, the diff does not show the change. It only shows the file as it was when I made the comment. Even if I click "view file" it shows the old one. That means, in order to verify that the change satisfied my request, I need to leave Github, pull down the branch and find it myself. All while Github tells me that file had "Changed since last view" without showing me the changes.
See previous discussion here: isaacs/github#750 (comment)
That Issue suggested posting here in 2021, but it doesn't look like anyone did.
All reactions