I m using Mercurial locally for a project it s the only repo there s no pushing pulling to from anywhere else To date it s got a linear history However the current thing I m working on I ve now realized is a terrible approach and I want to go back to the version before I started it and implement it a different way I m a bit confused with the branch revert update -C commands in Mercurial Basically I want to revert to version 38 currently on 45 and have my next commits have 38 as a parent and carry on from there I don t care if revisions 39-45 are lost for ever or end up in a dead-end branch of their own Which command set of commands do I need

hg update -r REV If later you commit you will effectively create a new branch Then you might continue working only on this branch or eventually merge the existing one into it

Here s the cheat sheet on the commands hg update changes your working copy parent revision and also changes the file content to match this new parent revision This means that new commits will carry on from the revision you update to hg revert changes the file content only and leaves the working copy parent revision alone You typically use hg revert when you decide that you don t want to keep the uncommited changes you ve made to a file in your working copy hg branch starts a new named branch Think of a named branch as a label you assign to the changesets So if you do hg branch red then the following changesets will be marked as belonging on the red branch This can be a nice way to organize changesets especially when different people work on different branches and you later want to see where a changeset originated from But you don t want to use it in your situation If you use hg update --rev 38 then changesets 39 45 will be left as a dead end a dangling head as we call it You ll get a warning when you push since you will be creating multiple heads in the repository you push to The warning is there since it s kind of impolite to leave such heads around since they suggest that someone needs to do a merge But in your case you can just go ahead and hg push --force since you really do want to leave it hanging If you have not yet pushed revision 39-45 somewhere else then you can keep them private It s very simple with hg clone --rev 38 foo foo-38 you will get a new local clone that only contains up to revision 38 You can continue working in foo-38 and push the new good changesets you create You ll still have the old bad revisions in your foo clone You are free to rename the clones however you want e g foo to foo-bad and foo-38 to foo Finally you can also use hg revert --all --rev 38 and then commit This will create a revision 46 which looks identical to revision 38 You ll then continue working from revision 46 This wont create a fork in the history in the same explicit way as hg update did but on the other hand you wont get complains about having multiple heads I would use hg revert if I were collaborating with others who have already made their own work based on revision 45 Otherwise hg update is more explicit

After using hg update -r REV it wasn t clear in the answer about how to commit that change so that you can then push If you just try to commit after the update Mercurial doesn t think there are any changes I had to first make a change to any file say in a README so Mercurial recognized that I made a new change then I could commit that This then created two heads as mentioned To get rid of the other head before pushing I then followed the No-Op Merges step to remedy that situation I was then able to push

I d install Tortoise Hg a free GUI for Mercurial and use that You can then just right-click on a revision you might want to return to - with all the commit messages there in front of your eyes - and Revert all files Makes it intuitive and easy to roll backwards and forwards between versions of a fileset which can be really useful if you are looking to establish when a problem first appeared

I just encountered a case of needing to revert just one file to previous revision right after I had done commit and push Shorthand syntax for specifying these revisions isn t covered by the other answers so here s command to do that hg revert path to file -r-2 That -2 will revert to the version before last commit using -1 would just revert current uncommitted changes

IMHO hg strip -r 39 suits this case better It requires the mq extension to be enabled and has the same limitations as the cloning repo method recommended by Martin Geisler If the changeset was somehow published it will probably return to your repo at some point in time because you only changed your local repo

[version-control] Mercurial — revert back to old version and continue from there

The answers above were most useful and I learned a lot. However, for my needs the succinct answer is:

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

where ${1} is the number of the revision or the name of the branch. These two lines are actually part of a bash script, but they work fine on their own if you want to do it manually.

This is useful if you need to add a hot fix to a release branch, but need to build from default (until we get our CI tools right and able to build from branches and later do away with release branches as well).

Examples related to version-control

• How can I switch to another branch in git? • Do I commit the package-lock.json file created by npm 5? • Project vs Repository in GitHub • Remove a modified file from pull request • Git push: "fatal 'origin' does not appear to be a git repository - fatal Could not read from remote repository." • Git: How to squash all commits on branch • git: updates were rejected because the remote contains work that you do not have locally • Sourcetree - undo unpushed commits • Cannot checkout, file is unmerged • Git diff between current branch and master but not including unmerged master commits

Examples related to mercurial

• Convert Mercurial project to Git • Mercurial: how to amend the last commit? • Discard all and get clean copy of latest revision? • Mercurial undo last commit • How to save username and password with Mercurial? • Mercurial — revert back to old version and continue from there • Is there any way to delete local commits in Mercurial? • How to correctly close a feature branch in Mercurial? • How can I switch to a tag/branch in hg? • What is the difference between hg forget and hg remove?

Examples related to branch

• Get git branch name in Jenkins Pipeline/Jenkinsfile • Why do I have to "git push --set-upstream origin <branch>"? • Your configuration specifies to merge with the <branch name> from the remote, but no such ref was fetched.? • When does Git refresh the list of remote branches? • Fix GitLab error: "you are not allowed to push code to protected branches on this project"? • Git push: "fatal 'origin' does not appear to be a git repository - fatal Could not read from remote repository." • Git: Merge a Remote branch locally • git pull from master into the development branch • Depend on a branch or tag using a git URL in a package.json? • How can I copy the content of a branch to a new local branch?

Examples related to dvcs

• Pushing to Git returning Error Code 403 fatal: HTTP request failed • Git push won't do anything (everything up-to-date) • Mercurial — revert back to old version and continue from there • How do I show the changes which have been staged? • How can I stop .gitignore from appearing in the list of untracked files? • Undo working copy modifications of one file in Git? • What's the best three-way merge tool? • What is the Difference Between Mercurial and Git?

Examples related to revert

• How do you revert to a specific tag in Git? • How do I revert an SVN commit? • How do I "un-revert" a reverted Git commit? • git revert back to certain commit • Reverting to a previous revision using TortoiseSVN • Remove specific commit • Reverting single file in SVN to a particular revision • How can I revert a single file to a previous version? • Mercurial — revert back to old version and continue from there • git status shows modifications, git checkout -- <file> doesn't remove them