views:

51

answers:

2

Myself and one other developer had been merging and pushing our work to a non-master branch called toolwork. That way, we didn't impact the rest of the team. My topic branch was called DPM-93 and my git workflow was this.

# do some work
git checkout DPM-93
git commit -m "did some work"

# catch up
git checkout toolwork
git pull origin toolwork

# rebase my topic branch
git checkout DPM-93
git rebase toolwork

# merge and push my changes
git checkout toolwork
git merge --no-ff DPM-93
git push origin toolwork

That was mostly working fine until I accidently issued these git commands

git checkout toolwork
git pull origin master

At that point, a bunch of new stuff showed up in branch toolwork and I'm not sure how to get rid of it short of deleting my workspace and re-cloning from the repo.

Is there any way to back this out to the state before the pull?

+2  A: 

You can use git log to find the SHA-1 of the revision you want to be at the head of your toolwork branch, then use git reset --hard <SHA1> to revert your working copy to that revision.

Back everything up first! And re-read the man page for git reset to make sure it's doing what you want.

EDIT: Oh yes, ORIG_HEAD should contain the right SHA-1. But check first.

Cameron Skinner
Didn't see you answer at first. `git reset` is right (even though a bit dangerous as you rightfully mention). +1
VonC
+4  A: 
git reset --hard ORIG_HEAD 

From the git reset man page (if you just did the pull):

Undo a merge or pull

$ git pull                         (1)
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard                 (2)
$ git pull . topic/branch          (3)
Updating from 41223... to 13134...
Fast-forward
$ git reset --hard ORIG_HEAD       (4)
  1. Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later.
  2. "pull" has not made merge commit, so "git reset --hard" which is a synonym for "git reset --hard HEAD" clears the mess from the index file and the working tree.
  3. Merge a topic branch into the current branch, which resulted in a fast-forward.
  4. But you decided that the topic branch is not ready for public consumption yet.
    "pull" or "merge" always leaves the original tip of the current branch in ORIG_HEAD, so resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit.

See HEAD and ORIG_HEAD for more.

VonC
@VonC: Would it be okay to use `git rebase -i ORIG_HEAD` to delete the unwanted commits, assuming no one has yet pulled from master?
unutbu
@unutbu: I believe the end result of such a rebase would be similar to a `git reset` in this case.
VonC
Thanks, @VonC. Sorry for the silly question. Somehow I didn't realize that `git reset --hard` not only alters the working tree and index but also removes the parent pointer in the DAG.
unutbu