How to revert a pull request that was merged to repo I forked from, instead being merged to my copy of that repo

Question

I forked from repo "A". Named my repo "B". Pulled it down locally. Made changes, committed, pushed. Created pull request with a goal to merge only to origin/master of repo "B", but since it was a forked repo, default settings on BitBucket had it merged to repo I forked from, repo "A".

So now, the master of repo "A" has my changes, that were not supposed to be there. They were supposed to end up in a master of my "B" repo.

BitBucket has a "revert" button on pull requests but I am getting this message.

I tried "git revert -m 1 commit-hash" and am getting this error..

How can I revert that pull request and have repo "A" back to the state before the merge happened?

I went over many answers but there was no similar case.

Answer 1

I didn't know the solution will be so easy. The answer I found here How do I revert a Git repository to a previous commit? made it work with only two commands. History is preserved, and repo A is at the same state before the merge. A new revert commit is added.

Answer 2

Assuming you have permissions on repo A to do that, you can rewrite the history of its master and remove all the wrong merged commits .

For example, if repository A had a clean history up to commit1, then the PR got merged so the rest of the history contains commits from that wrong PR, but also "good" commits from other PRs, then in that repo:

git checkout master && git pull      # be sure to work with the latest
git rebase -i commit1

That will open your favorite editor showing one commit per line. Remove all the lines corresponding to "bad" commits (including any merge commit from that PR) and keep the "good" ones. Save and exit.

If conflicts happen (somebody based their work on something from that PR), you'll need to manually fix it and then git rebase --continue .

Once the rebase is done, you have the branch history clean as if the PR was never merged. But, and here's where you need permission to do this, you need to republish it in the remote with git push -f origin master and make sure to report it to anybody who may have checked out the old wrong version of it (they would have to delete+create the repo, or the branch, or if they had actually done some work on top of it they should probably delete+create the branch anyway and use stash or cherry-pick to reproduce the work on top of it).

---

If no "good" commits have been mixed with "bad" ones, then the solution is much simpler. For example, if repository A had a clean history up to commit1 and then everything else is "wrong", you can just reset the branch to that last good commit:

git checkout master && git pull
git reset --hard commit1
git push -f origin master

Again, you need write permissions for the branch master and warn anybody who may have based their work on it.