3

When I merged https://github.com/nodemcu/nodemcu-firmware/pull/1627 a few days ago, a snap from the dev branch to the master branch, I chose "squash and merge" instead of a regular "merge commit". I can't simply revert the PR and create a new PR from dev as there have been commits to dev in the meantime.

Is there a sensible way to fix this? Maybe something like https://stackoverflow.com/a/28497372/131929?

Community
  • 1
  • 1
Marcel Stör
  • 22,695
  • 19
  • 92
  • 198

3 Answers3

2

Although I fully agree with @torek's answer, he left out some of the details. You can indeed revert the commit on the master branch. There are two ways of doing this:

  • you can change the history and use git reset HEAD~1. This only works if you didn't commit anything else to the master branch in the meantime and you'll have to push using git push -f. Using this command will remove the commit from the history.
  • or you can use git revert REV, where REV is the hash of the commit. In this case an extra commit will be created which undoes the exact work of the commit.

Then the easiest way to have just this work in a new pull request would be to first check out the exact work you had: git checkout REV. Then you can create a new branch (git checkout -b NAME), push this branch and create a new pull request.

Dekker1
  • 5,565
  • 25
  • 33
  • You forgot to mention `git rebase -i` – grepsedawk Dec 08 '16 at 00:25
  • That's what I ended up doing (`git revert`). Hadn't I committed something to `master` in the meantime GitHub would have supported this whole operation even w/o resorting to the CLI. Since the GitHub one-click revert failed due to conflicts I had to `git revert REV`, fix the conflicts and then `git revert --continue`. – Marcel Stör Dec 08 '16 at 07:33
1

Since "squash and merge" makes a new regular (non-merge) commit out of the diff based on the commit(s) you had in your pull request, you can indeed simply revert that one single commit. You will just need to (re)open a (new) pull request.

torek
  • 448,244
  • 59
  • 642
  • 775
0

All of the answers on this question are definitely viable, but the best answer is probably git rebase -i

You would type:

git rebase -i HASHOFSQUASH~1

IE:

git rebase -i 2fa05ad3c0e92103a137c57c388ac42b3d07f5ab~1

Which will give you:

pick HASHBEFOREYOURS commit message 2
pick YOURHASH commit message 1

Edit the squash merge, then save the file and exit. (esc :wq if it's vim)

Then, it'll run through the rebase and when it's done, the squash commit will be gone. Simply git push -f to push that as your new master branch.

grepsedawk
  • 3,324
  • 2
  • 26
  • 49
  • Yeah, interactive rebasing to get rid off the squashed commit would leave `master` with a clean commit history. However, I tried to avoid force-pushing to a public and widely used repo whenever possible. – Marcel Stör Dec 08 '16 at 07:30