27

I think I've messed up here.

I made a few changes to my code from a last commit adding new functionalities and realized that some other piece of code was now acting strangely. I decided to Roll back to an old commit (pushed to remote as well) in order to test if that functionality was working by then.

Before I pressed Rollback, I committed my currently made changes because I did not want to lose them. After committing (not pushing to remote), I did the rollback to that old commit. (note that there were quite a few commits inbetween the commit i roll backed to and the one i committed just now).

All worked fine and my code reverted to that commit. The functionality was misbehaving there in that commit as well so I decided to come back to my most recent commit.

However, I knew not how to do that except Rolling Back to the latest commit. But it gave me an error.

error: a cherry-pick or revert is already in progress
hint: try "git cherry-pick (--continue | --quit | --abort)"
fatal: revert failed
(32768)

Now, it seems like most of things are back but the current version of code isn't the same as my last commit. It is somewhere in between. =(

What did I do wrong? [I'm not asking out of innocence, I know I did it wrong ;)]

What was the right way of doing it? [I think I should have branched first]

atastrophic
  • 3,153
  • 3
  • 31
  • 50

1 Answers1

35

I do not know what github for Mac rollback does, but it seems that you would be better off using command line to resolve the issue at hand:

git cherry-pick --abort - to stop any cherry-picking in progress

git branch -va - will show you where are your pointers right now

make sure your working directory is clean: git status - should not show any modified or staged files

git stash - if anything modified still present

git reset --hard your_local_branch github/remote_branch - make local branch reflect the state as it is on the remote side. obviously you don't need to do a reset if your current branch will point to the same commit as the remote. If you're in detached HEAD state (git status will tell you about it) then to come back to the normal state just checkout your local branch.

Now decide what you actually want to achieve:

I. get rid of the faulty commit?

Use interactive rebase and remove the line with faulty commit, then force push to the remote repo on github (say faulty commit happened 10 commits ago)

git rebase -i HEAD~11

II. revert faulty commit? - wouldn't recommend to do that after some other commits, unless you're absolutely sure that the following commits didn't touch the same piece of code. This will effectively create a reverse commit (if line was added by faulty commit it will be removed by revert and vice versa)

git revert {commit-sha1}

III. Amend faulty commit? use interactive rebase, but instruct it to stop at faulty commit for amending. When it does stop edit the change and continue rebasing, then force push to the remote branch (use rebase command from the solution I )

After you're done if anything was stashed use git stash pop to bring the changes back.

hope that helps!

Eugene Sajine
  • 8,104
  • 3
  • 23
  • 28