Mercurial: how to undo last unpushed commit?

I have accidentally made a commit to my local repository. To be more specific, I committed changes to lots of files all at once, when I meant to commit them one at a time.

How do I undo this commit and get my working copy back to the state it was before the commit so I can do what I should have done in the first place?

I have not pushed or pulled or anything else since the commit.

You may suspect this is a duplicate, so I will explain why the following questions are different, or do not answer my question:

Mercurial undo last commit

An answer to this one states that you can do this with hg commit --amend, but does not explain how or give an example of doing this. The mercurail help does not spell it out for me either.

How do you "rollback" last commit on Mercurial?

States to use hg rollback. This command is apparently deprecated, I tried using it anyway, but I got the messge: no rollback information available. A shame this doesn't work as this would be a really intuitive way to achieve what I want.

Solution 1:

Based on information from this question:

hg strip --keep --rev .
--keep: do not modify working directory during strip
--rev . (the dot denotes the last commit. read sid0's answer regarding descendants)

For people more familiar with git language, you are looking for git reset --mixed HEAD^

hard which would discard your changes, making your work "disappear" (I assume that is not an option)

soft would undo the commit, but keep previously committed files indexed (that is, tracked)

mixed keeps your changed files in place, but tells the index to undo the commit. in git-speak: git st would say Changes not staged for commit

See also git-reset docs , Difference git reset soft/mixed, git/hg Command equivalence table

Solution 2:

Ok, I think I've found the answer, it's to enable the strip extension, and use the following command:

hg strip -r -1 --keep

This strips the last revision from the repostiory (the -r -1 bit), and the --keep option means no changes are made to the working copy. So you end up with a working copy exactly as it was just before the commit, and no last commit in the repository.

I'm no mercurial expert, so use at your own risk.

Solution 3:

What I'd do in this situation is make a new branch that has the changes I want before I ever thought about removing the bad change-set. So in this case I'll need to go back to the revision before I made the bad commit, re-do my changes and then make multiple commits, one for each file.

Step by step:

1) Go back to before the bad commit.

% cd <top of repo>
% hg log -l 5
<identify the last good revision>
% hg update -r <last good revision number>

2) Remake the changes: I'd get a patch which describes the changes I want, and apply it to the tree. (I'm assuming tip currently points to where we started)

% hg diff -r .:tip | patch -p1
patching file a/b/c/d
patching file a/b/e/f

3) Make new commits: We're now back at the state before you made the commit you wanted to split up. Do hg status and look at the modified files, make sure everything is as you expect. At this point you can either commit the files one by one by naming them on the command line, or use an extension like record or crecord to interactively select them.

% hg commit a/b/c/d
% hg commit a/b/e/f

...or...

% hg crecord
<select files in UI>
% hg crecord
<select files in UI>

You'll end up with a repo that looks like this:

o----o----B
      \
       \
        --o----o----o----T

Where B is the old bad commit, and T is the new tip of the repo. If you want to then make that branch as closed, so it doesn't show up in logs / etc, you can...

% hg update -r <revision B>
% hg commit --close_branch
% hg update -r tip

If you want to remove it completely, you can strip it.

% hg strip -r <revision B>

Either way, your log will look like nothing ever happened.

Solution 4:

commenting and elaborating on @crobar's post cause # of characters is not enough.

when doing a local commit (no push) then run hg strip -r -1 --keep, it deletes your previous commit AND preserves your list of files waiting to be committed. basically this is a full undo.

if i use hg strip -r -1 without the --keep, it still deletes your previous commit BUT when i try to list the files to be committed it can't find a change so I wouldn't recommend doing this.

if i do a commit then do a push (to remote) then do hg strip -r -1 --keep, it does exactly what its supposed to do BUT when you do another commit then push, it creates another branch.

I.E. 

o----o----Branch (local)
      \
       \
        --o----o----o----Branch (with previous push)

my source/reference: testing these scenarios