-
Notifications
You must be signed in to change notification settings - Fork 131
Updating base branch in PR does not recalculate files in diff #750
Comments
@beldaGR |
I've encountered this in a more specific form:
In that case, GitHub does not update the PR's commits and diffs. In my experience, changing the base branch on a still-open PR does update them as expected. I have support thread open with GitHub containing a detailed repro case. |
I'm seeing this where I've made changes to |
I was having the same issue where the PR base branch changed, but the PR diff view was outdated even after multiple browser refreshes. Editing the PR Base to a different branch, then changing it back fixed it. |
Use simple git merge works |
@mihelich Did you ever hear back from GitHub Support? |
Changing the base branch away from Master then back also worked for me, but this is clearly a bug.
This is a heavy work-around that due to my team's workflow I now have to do regularly. Needs to be fixed. |
I am also interested in what's mentioned above, if I may be of use as an additional voice for this issue. Perhaps there should be a hook to regenerate the PR or reload the diff when the base branch changes. |
Is there an API endpoint or action that could be (ab)used to programmatically force a refresh? I guess that, as a last resort and as per the comments above, the API could be used to change the base branch to a different one, and then back to the original one. But it'd be ideal to find something less intrusive than that. |
I am amazed about this bug being reported in 2016 and two years later still not fixed. It seems like a basic feature for pull requests. |
Running into a similar version of this - files changed tab is showing file differences based on commits instead of on the diff. |
Simply switching base branch back and forth works. |
I just encountered this on GitHub Enterprise, Version 2.17.1 (sha 4559402). I used the workaround of switching the target branch and then switching it back real quick, but it's not a very satisfactory solution. If another developer had the page open, and clicked "merge" between my two changes, wouldn't the PR be merged onto the wrong branch? |
Yes, the diff in a PR should always be recomputed according to the latest version of the base branch. |
FYI, answer from Matt at Github support:
|
This worked for me! Thanks! |
Just want to add that the three-dot vs two-dot diff behavior mentioned by @monperrus explained, in my case, why I was seeing different diffs locally and on Github - even after changing the base branch to force a refresh. A |
Same here, clearly a bug in github files view on the PR |
I just experienced that too. But then, I saw a button (can't attach a screenshot because I already clicked on it) with the label |
This has been happening with our repo regularly since the new year for some reason.
|
Still a bug, and a big problem with repository maintainers who don't have access to rebase branches/PRs or change the default branch. I wish there were a button/function to update PR diffs. |
Open a ticket at https://support.github.com/request and maybe with enough +1's, they will fix it. |
I don't know if that should used for general bug reports. Try searching https://github.com/github/feedback/discussions for this, or filing there if not already there, referring back here. |
I think we should follow this guy's advice: #750 (comment) |
Actually, my advice there is somewhat outdated. The current best practice is to search https://github.com/github/feedback/discussions: if you find a discussion for this, chime in there, & refer here (if not already linked); else, open 1 up to do that. |
I think there's a bug in your new feature from August 15th. The diff showed 5 file changes but it introduced a lot more. When you revert the merging commit, there are 26 changed files. Causes confusion and headache when investigating. I'd rather not have the feature appear at all, vs. having to solve the mystery of why previously reverted commits are showing up in master.
The text was updated successfully, but these errors were encountered: