Pull request erroneously reports as merged when it's not merged

Issue #4998 resolved
John Hsu
created an issue

We actually did not approve the merge but pull request system shows the status as merged:


Comments (9)

  1. Dylan Etkin

    Hi John,

    If you pushed the changes into the destination repository manually that would have automatically changed the state of the pull request to merged.

    Could this have been what happened?



  2. John Hsu reporter

    Hi Dylan,

    The patch was never merged, and double checking with our current default branch, it does not look like the changes from the pull request are there either.

    Thanks, John

  3. Patrick Kaeding

    Hi John

    The system should mark a pull request as merged if the commits in it are merged into the destination branch manually, even if the 'Merge' button was not clicked on the website. It looks like that is what happened here.

    Here is the tip commit from the pull request, in the destination repo: https://bitbucket.org/jashar86/gazebo/changeset/add7700a919f

    And here it is in the destination: https://bitbucket.org/osrf/gazebo/changeset/add7700a919f9480de54b8616decf973b1a04998

    Hope that clarifies what happened!

  4. Patrick Kaeding

    Hi John

    Hmm, thanks for the clarification. I will dig deeper into this.

    Looking at the history of the pull request, it looks like when it was created, the tip revision on the source branch was 03cb085e2c5e (which doesn't seem to exist anymore in the jashar86/gazebo fork), and on 2012-10-18, user 'nkoenig' updated it to use add7700a919f as the tip. add7700a919f is the revision I linked to above, which is already in the destination repository (osrf/gazebo).

    The really strange thing is that the change attributed to 'nkoenig' on 2012-10-18 is marked as being an 'internal' update to the pullrequest, which means that the system made the update in order to maintain data integrity. Was the jashar86/gazebo repository stripped around then?

    The replacement pull request you linked above has a different commit, 59a4454. Is that meant to be the exact same commit that should have been in the original pull request, or did the developer re-create the fix, and open a new PR?

    Thanks, Patrick

  5. Log in to comment