1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues

Issues

Issue #7286 resolved

Pull request somehow copied to another pull request.

Austin McDonald
created an issue

1) User bpm opens pull request #124. 2) User apm opens pull request #125. 3) User apm reviews #124, approves. 4) User bpm merges #124. 5) User apm notices that bpm is shown as having closed both #124 and #125. Additionally, the contents of #125 have been overwritten with the contents of #124 (the source branched changed, apparently).

I don't want to rule out user error here, but we're pretty sure we couldn't have changed the source branch of #125 and also merged it on accident. It looks like a bug on Bitbucket's end.

repository: https://bitbucket.org/realityfoil/lambda

124: https://bitbucket.org/realityfoil/lambda/pull-request/124/factor-out-inputmanager

125: https://bitbucket.org/realityfoil/lambda/pull-request/125/refactors-column-and-voxelreference-and/diff

126 contains the original content of #125: https://bitbucket.org/realityfoil/lambda/pull-request/126/column-and-voxelreference-take-2/diff

Let me know what more information would be useful.

Comments (7)

  1. Brodie Rao

    Hi Austin,

    The source branch for a pull request can only be changed through the PR edit/update form. Bitbucket will never change that automatically.

    Would you happen to be doing any rebasing in your repo? That might cause pull requests to get into the weird, inconsistent states you're seeing. We currently don't have proper support for rebasing in PRs.

    If you aren't doing any rebasing, I'll have to do more digging to figure out exactly what happened.

  2. Austin McDonald reporter

    I definitely remember rebasing at some point today, but I was pretty sure it wasn't #125; it might have been though. Is there some way to detect rebasing?

    Thanks for looking into it.

    Any idea when bitbucket's PRs might support rebasing? If that's what's at fault here, I would've expected it to just update the branch that it was pulling from. Merging is definitely not the right thing to do.

  3. Brodie Rao

    Here's what I can see in the history:

    • For #124, it's been updated once (so its source commit has had two different values). The second commit is a descendant of the first, so there was no rebasing there. That pull request should be OK.

    • For #125, its source commit was never changed (it only had one value), but that commit is no longer on the source branch. That would indicate to me that someone rebased that branch.

    • For #126, its source commit also never changed (it only had one value), and it was merged in and its branch was closed/deleted.

    125 and #126 are at different commits, so I don't think anything got messed up there. For all three PRs, their source commits are all part of their destination branches, so I think their merge state is correct.

    If you look at #124's list of changes, it looks like it incorporates all of the commits in #125. It sounds like someone merged the commits from #125's source branch into #124's source branch (before #124 was merged). So merging #124 had the side effect of marking #125 as merged (since those commits are now in the destination branch).

    I don't think any rebasing you've done has had any hand in causing this situation. It sounds like someone just merged one PR into the other without realizing it, and then merging one caused both to be marked as merged.

  4. Log in to comment