PR timeline says “merged into master” when the actual target was a feature branch #209384
Unanswered
lsantire
asked this question in
Pull Requests
Replies: 1 comment
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Bug
Body
Context
I observed an incorrect merge-destination label in a pull request timeline.
There were two dependent pull requests:
AmasterBAIn other words, the child PR was intended to merge into
A; only the parent PR targetedmaster.Sequence that produced the issue
A.BintoA.masterintoA.Ato the remote.B → A) as merged.The relevant Git operations were equivalent to:
These steps describe the observed incident. I have not independently reproduced the issue in a public test repository.
Actual behavior
The child PR's UI timeline displayed a message equivalent to:
However, the merge destination was branch
A, notmaster.At the time the message appeared:
A → master) remained open.master.A.Verification through the API
We checked both the PR metadata and its recorded merge event through GraphQL. The values below use the same generic branch names as the rest of this report.
masterMergedEvent.mergeRefNameAbaseRefNameAThe historical merge event and the current PR base therefore agree with the actual feature-branch merge, while the UI names the default branch.
Expected behavior
The timeline should identify branch
Aas the merge destination, matching the recorded merge event.Automatically marking the child PR merged is consistent with its changes having been merged into its base. The problem is the branch name displayed in that event.
Impact
The message incorrectly suggested that changes had landed in the protected default branch. We had to inspect the API and Git history to verify that no merge into
masterhad occurred.Related report
https://github.com/orgs/community/discussions/198570 describes a different PR timeline event displaying the wrong branch name. This may be useful context; I do not know whether the two reports share a cause.
All reactions