Updating base branch in PR does not recalculate files in diff

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.

@beldaGR

@beldaGR ~~Since this isn't @github support, make sure you contact them, & refer back to this issue. It'd be much appreciated to update w/ response & resolution, when there is.~~ Now do as detailed in #750 (comment).

I've encountered this in a more specific form:

Close an existing PR.
Change its base branch, while closed.
Reopen the PR.

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 develop and a feature branch continues to show old state. Closing and re-creating the PR continues to show old state without the base branch changes.

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

@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.
Here's how to reproduce in my case (not sure if my online editor activity did something)

Have multiple PRs submitted by the same person as they go through and change things sequentially (each incorporating their previous PR's changes)
Use the online editor to make changes before merging the first PR into Master
review changes to the next PR and any changes you made in the online editor are not reflected
fix this by changing the base branch (ideally to the last-fixed PR's branch) and then change it back to Master...

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.
Ex, starting with develop as the base branch which got updated after PR was created:
switch base branch to staging
switch base branch back to develop
Done

You just have to merge master(or the base branch you desire) into the branch that has the PR open and then GitHub will recalculate the diffs.

Well, the idea is to not have to do that.

You just have to merge master(or the base branch you desire) into the branch that has the PR open and then GitHub will recalculate the diffs.

Well, the idea is to not have to do that.

Question: if the base branch introduces a breaking change for the PR, wouldn't it make sense to build and test the new commit before merging the PR? In other words, shouldn't it be up to the PR owner to make the merge themselves?

If the base branch introduces a breaking change for the PR, wouldn't it make sense to build and test the new commit before merging the PR?

Totally! But this thread is not so much about if the base branch introduces a breaking change for the PR, but more when the base branch fast-forwards to a point midway into the PR's history:

base .. a .. b .. c .. d .. e .. f .. g .. topic

Initially, the PR shows a diff including a–g. And if we add to topic:

base .. a .. b .. c .. d .. e .. f .. g .. h .. i .. j .. k .. topic

then the PR diff is updated correctly as a–k.

But if a–e is merged into base, we end up with:

base .. f .. g .. h .. i .. j .. k .. topic

The PR diff should show f–k, but it actually still shows a–k (it's cached, I suppose), which doesn't reflect the current state of the repo, and is unhelpful for reviewing purposes.

In other words, shouldn't it be up to the PR owner to make the merge themselves?

Probably so, but the PR owner and reviewers should have some way of knowing about it, and seeing the updated diff, which is what this PR is about.

I think you're describing this scenario:

.. a .. b .. c .. d .. e .. f .. g .. topic
    \
      x .. y .. base

which should now be converted to a 3-way diff, which Github supports, except that it doesn't notice that the diff needs to be updated. This should be fixed too. It can still be the PR owner's responsibility to fix a breaking change (CI should detect it and re-run tests on the new merge), but there's no reason for the PR diff to be out of date.

TL;DR: Github recomputes the diff when topic changes, but doesn't recompute it when base changes. It should recompute the diff when either changes.

Hope this helps.

What happens if we merge that PR.

I like how github ignores this issue, says it's working as intended, and hopes everyone just goes away.

Try to rebase with the target branch.

@mryellow

I like how github ignores this issue, says it's working as intended, and hopes everyone just goes away.

@mryellow This isn’t actually Github Support, so we’re just preaching to the choir here, and/or arguing amongst ourselves. They can be reached at support@github.com, and then if you wanted to quote their reply here so that everyone is brought up to speed, then 👍.

Try to rebase with the target branch.

@aniketrathi The point is that you shouldn’t have to do that or know to do that.

if you wanted to quote their reply here so that everyone is brought up to speed, then

Someone did so earlier.

We show what's called a "three-dot diff"
It sounds like you'd rather see a "two-dot diff"

"Working as intended"

#750 (comment)

@mryellow

@mryellow The three-dot diff also doesn't work, isn't brought up to date when the base branch ref moves.

from Github support re. Ticket 1192918:

Hi Arya,

Thanks for writing in!

As you correctly stated, what you are describing here often happens when a pull request's base branch is updated. I'm afraid that currently, we do not automatically perform sync pull request or track changes when the base branch is updated.

To avoid confusion, we recommend regularly merging the main branch into the topic branch. Other users have also found this workaround to be effective i.e. switch the base branch of the pull requests to a random branch then switch it back.

I can see how it would be useful to automatically sync the PR when the base is update. We've received similar feedback from other users as well and shared it with our Product team for consideration. I'll add a +1 on it on your behalf.

Please let me know if you have any other questions.

Regards,
Peter
GitHub Support

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.

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)

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.

Navigation Menu

Repository navigation

Updating base branch in PR does not recalculate files in diff #750

23 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Updating base branch in PR does not recalculate files in diff #750

Description

Activity

TPS commented on Aug 24, 2016

mihelich commented on Jan 25, 2017

mryellow commented on May 23, 2018

KrisKnabel commented on Jun 1, 2018

alexlevy0 commented on Jul 12, 2018

cxw42 commented on Aug 3, 2018

Methodician commented on Aug 5, 2018

qci-balagula commented on Aug 24, 2018

dato commented on Mar 3, 2019

aipirvu commented on Apr 3, 2019

ccemeraldeyes commented on May 2, 2019

jgonzalezd commented on May 16, 2019

23 remaining items

aryairani commented on Jun 2, 2021

Levi-Lesches commented on Jun 3, 2021

aryairani commented on Jun 4, 2021

aniketrathi commented on Jun 4, 2021

mryellow commented on Jun 6, 2021

aniketrathi commented on Jun 6, 2021

aryairani commented on Jun 9, 2021

mryellow commented on Jun 9, 2021

aryairani commented on Jun 14, 2021

aryairani commented on Jun 15, 2021

kekoziar commented on Jun 30, 2021

aryairani commented on Jun 30, 2021

TPS commented on Jun 30, 2021

aryairani commented on Jul 1, 2021

TPS commented on Jul 1, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions