GitHub's "rebase and merge" : author's pull request complains: "branch has unmerged commits"

Good day,

GitHub’s pull request “Rebase and merge” feature seems to leave the author with this annoying message about unmerged commits:

> “This pull request is closed, but the <branch_name> branch has unmerged commits”

The scenario I experienced this in was:

 * primary public open source repo

 * fork it to myself

 * do some work on a topic (feature) branch

 * create a pull request to upstream maintainer

 * maintainer performs “Rebase and Merge” operation and closes PR

seems that the github rebase is NOT the same as git rebase …
https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/
https://help.github.com/articles/about-pull-request-merges/

> “The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit. For more information about git rebase, see the “Git rebase” chapter from the Pro Git book.”

so my commits on the topic (feature) branch in my fork are dangling as far as git knows… github creates new commits during the rebase (retains authorship information), and the commit SHA’s from my branch are NOT directly applied
 (note that I can confirm that the resulting diff is applied to the master branch)


Ironically I couldn’t find a “GitHub Issues” section in github.com/github … so posting here to community forums for peer feedback

Should GitHub not handle this properly? The result of a GitHub rebase leaves the author of the pull request with this confusing (though factual) message. The implication is that many users will be confused. Their PR commits were rebased, PR closed. They can confirm that their changes were delivered to upstream master, yet the GitHub message stating : " This pull request is closed, but the <branch_name> branch has unmerged commits"!


PS: here’s an example PR https://github.com/cisco-system-traffic-generator/trex-core/pull/98

1 Like

Hi @mcallaghan-sandvine,

Thanks for this feedback! We’re always working to improve GitHub, and we consider every suggestion we receive. I’ve logged your feedback internally. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.

Please let me know if you have any other questions.

Cheers!

Hi Thank you for your reply!


Is it possible to get technical confirmation of whether or not this is a real issue, or perhaps mis-understanding of how to perform this action using GitHub?

note that i have confirmed that in this scenario, the repository maintainer is manually performing the rebase activity in git itself ; and not using GitHub’s rebase button


perhaps it could be argued that people should just use the GitHub interface … on the other hand they should be allowed to use git directly too

 - so this is the scenario that GitHub could handle better (hopefully this can be pushed into R&D as enhancement)

To make sure that we understand what happened here, it sounds like you’re saying that:

  1. You made a PR to a repository you don’t own from a non-default branch on your fork
  2. The repository maintainer checked out your changes locally
  3. Locally rebased your changes
  4. Locally merged them to master
  5. Pushed the new master to the repository in question
  6. Closed your PR without merging it

And what you would like to see is GitHub detect that this happened and not give you a warning about unmerged changes?

1 Like

indeed! I think you have correctly summarized what is happening, as well as the ideal scenario for github to detect it and report the activity correctly (if possible)

Great! Thank you for confirming. We will add these details to the existing feedback.

  1. You made a PR to a repository you don’t own from a non-default branch on your fork

I noticed this exact scenario today in a private repo where both the creator of the PR and the reviewer are member of the same org (the reviewer is owner,  the creator of the PR has write permissions)