"Update with rebase" results in a large change set with spurious commits

[alalazo]

Select Topic Area

Bug

Body

I am a maintainer and core developer of the Spack project https://github.com/spack/spack Today, it happened on 2 different pull requests in that project to click the "Update with rebase" button and get the UI display a large changeset. For instance on this PR spack/spack#36329 ( a one line change) I obtained the following:

The funny thing is that when I checked the 231 commits listed, they were all replicating our target branch - except the last one which was supposed to be the PR. To be clearer, when this happened the HEAD of the develop branch was 6aa4c29119ea241d2370d3e3ce6e35f76001219b and so was HEAD~1 of the PR branch.¹

I fixed the issue in this PR by force pushing to the user branch, but was wondering if this has been reported already, or if it is an issue on my side that somehow started today.

Footnotes

1. It feels like the pull request updated the branch, but was still trying to merge with the old develop commit. I didn't verify this hypothesis though. ↩

[keith]

We started seeing this yesterday as well. I just went to try and reproduce to file a bug report and it seems that I can't anymore

[keith]

I was wrong, we're still seeing it. Closing and reopening the PR also fixes the issue

[kadru]

I have the same issue with differents PRs, but is in a private repo.

[philippeauriach]

We have this issue as well on private repositories. It seems to be only a graphical issue, as merging result in a correct tree in master.

We found a workaround, to close and reopen the PR result in the proper list of commits being displayed.

[sjaeckel]

Same here, fixed it by amending the most recent commit on the source-branch and force-pushing it.

[ikex]

It's not just a graphical issue - it also affects other PR sections like "Files changed" (it shows difference in commits against the... snapshot main from the time when the PR has been created... it renders this part kinda cumbersome) and - what's even worse - triggers all pipelines affected by imported commits. So - for instance - if we "rebase" commits that contain changes to specific paths it will trigger those additional pipelines. Or - for instance - we have a specific case for dependabot PRs where commit linter treats those commits differently... if we pull those commits by "rebase" it will trigger a pipeline that will fail on commitlint, just because the PR is not by dependabot.

So i think it's not that minor issue and it affects us badly.

Currently we are rebasing locally and pushing changes to PRs.

[DarylCantrell]

GitHub staff here. Thank you for the bug report. This was caused by a new feature we are rolling out. We have deactivated it for the moment, and a permanent fix for this issue is in the merge queue. It is safe to rebase again.

If you have existing pull requests with redundant commits, it should suffice to close and then re-open the pull request. This causes the system to recompute the PR base commit and it should then display correctly.

Sorry for the trouble, and thanks for letting us know.

[pierresisson]

NOICE

[nguyta02]

We are facing an issue similar to this, but not sure.
@DarylCantrell - Has this been fixed ?