I have a mercurial repo with the following history (most recent commit at the top) on a feature branch:
mergeDefaultA
|
mergeDefaultB
|
C
|
mergeDefaultD
mergeDefaultXXXX are merge commits that came as the result of merging the default branch into the feature branch.
What has happened is commit C is screwed, but this was not noticed until after I had pushed mergeDefaultA to Bitbucket. What I want is the following picture:
exactlyWhatIsInMergeDefaultD
|
mergeDefaultA
|
mergeDefaultB
|
C
|
mergeDefaultD
Where exactlyWhatIsInMergeDefaultD is literally exactly what was the state of the code in mergeDefaultD. However, everything I'm reading seems to indicate either you can't undo a series of commits like this (only a single commit back) and even then many of the options aren't available once you've pushed "into the wild".
How do I achieve this?
If this was git, I'd do:
git revert mergeDefaultD
How do I do the same in Mercurial?
Here's what I think you want:
hg revert -r GOOD_REVISION_NUMBER --all
hg commit -A -m "reverting back to revision GOOD_REVISION_NUMBER"
Once that is committed, as soon as someone pulls from you (or you push to them) they will get the most recent revision containing only the good stuff. If they ever do want to go back to the bad stuff, you could always update to that revision:
hg update -r BAD_REVISION_NUMBER
To expand a bit on Harvtronix' answer (which is fine, by the way):
One simple way is to revert to the old revision number ('GOOD') and commit. Note: reverting means that you set the files to the same content as in revision 'GOOD', you don't go back down the tree to that commit. If you did, you would indeed branch off and have two heads.
hg revert -r GOOD --all
hg commit -m "all is good now"
Another way can be to only throw out revision C (if I read your explanation correctly, it's actually just C that is causing the issue). 'hg backout'will introduce the reverse of C in your working directory, so you can then commit it.
hg backout -r C
hg commit -m "Backed out C"
Finally, one last option is to close the bad branch, update to the last commit that was fine and commit further there:
hg up -r BAD
hg commit --close-branch -m "This head is bad"
hg up -r GOOD
... continue here ...
What is the difference between the mercurial commands,
hg strip
hg backout
hg revert
All these commands basically are used to revert/undo the effects of an earlier changeset.
hg strip removes the changeset and all its descendants from the repository. It will be as if the changes never existed. Be careful when using this on public changesets as it will not remove it from any other repository and you'll get them back next time you pull.
hg backout creates a new changeset to reverse the effect of an earlier changeset. The old changeset will still remain in the repository but so will a new changeset to remove the changes.
hg revert with a revision updates the working copy to the specified revision. If you then commit that working copy it will have the effect of reverting all changes since.
Other answers with more info on revert and backout:
What is the difference between hg revert and hg backout?.
Mercurial — revert back to old version and continue from there.
At certain moment of time I had to build Jenkins pipeline where POM files should be reverted each time the job starts. And the problem which I have faced is: how to revert all POM files reversively.
Since this answer is one of the first on google, I want to contribute my solution for people with same problem
hg revert */pom.xml
I typed
$ hg addremove
but later realized that some of the files should not be part of the commit. What I should have done was to add these files to .hgignore and after that run addremove and commit.
Is there a way of fixing this?
If you have not commited yet just use hg forget fileToForget or use Tortoise to remove the files.
If you have committed and you don't mind the files to be part of history, just forget them and commit again.
If you don't want them to be part of your repository history, and if commiting them is the very last operation you've made, you can try to rollback (use hg rollback or go in the recovery menu in Tortoise). You will have to forget the file and then commit again
If you're dealing with too many files, you can try to automate the task by getting a list of all added files, forgetting them, modify you .hgignore and do the addremove again.
Example of the first step in powershell with no commit made
hg status --added --no-status | foreach-object {hg forget $_};
To undo an addremove you did not commit yet simply run:
$ hg revert --all
I made a mistake and removed a file. I'd like to go back to my previous commit!
I tried with revert and backout with had no luck...
Any tip?
Edit: I did exactly this:
hg forget file
hg commit -m "Blah"
hg push
The revision number of this last push is 17.
Now file is not tracked anymore. I'd like to get it back to revision 15 (not the inmediate previous rev, but one extra step back) as i do not want to keep working on the file in rev 16.
Found a solution:
hg revert file -r15 //(reverts file to revision 15).
If you have committed then you could update to previous version. If the file is version controlled, it is not going to go away. Thats what version control are for.
hg update -r "what is previous rev"
If you have removed a file and had not committed, then simply do the update and it will restore the file.
hg update
[edit: based on edited question]
hg revert file -r 15
hg update file -r 15
Try pulling version 15 and hg pull -r and then adding the file.
So I keep making a silly mistake in Mercurial. Often times, I'll start work without doing an "hg pull" and an "hg update." When I try to push my changes, I get an error.
Is there any way to delete my local commits so I can avoid creating multiple heads, branches, etc? I just want to delete my local commits, merge my changes with the tip, and then re-commit. Sounds simple, right? I can't seem to find any way to easily delete local commits so I can cleanly merge with the tip.
Again, I'm only trying to delete local commits made with "hg ci". I don't want to modify files, revert, etc.
Enable the "strip" extension and type the following:
hg strip #changeset# --keep
Where #changeset# is the hash for the changeset you want to remove. This will remove the said changeset including changesets that descend from it and will leave your working directory untouched. If you wish to also revert your committed code changes remove the --keep option.
For more information, check the Strip Extension.
If you get "unkown command 'strip'" you may need to enable it. To do so find the .hgrc or Mercurial.ini file and add the following to it:
[extensions]
strip =
Note that (as Juozas mentioned in his comment) having multiple heads is normal workflow in Mercurial. You should not use the strip command to battle that. Instead, you should merge your head with the incoming head, resolve any conflicts, test, and then push.
The strip command is useful when you really want to get rid of changesets that pollute the branch. In fact, if you're in this question's situation and you want to completely remove all "draft" change sets permanently, check out the top answer, which basically suggests doing:
hg strip 'roots(outgoing())'
If you are using Hg Tortoise just activate the extension "strip" in:
File/Settings/Extensions/
Select strip
Then select the bottom revision from where you want to start striping, by doing right click on it, and selecting:
Modify history
Strip
Just like this:
In this example it will erase from the 19th revision to the last one commited(22).
Modern answer (only relevant after Mercurial 2.1):
Use Phases and mark the revision(s) that you don't want to share as secret (private). That way when you push they won't get sent.
In TortoiseHG you can right click on a commit to change its phase.
Also: You can also use the extension "rebase" to move your local commits to the head of the shared repository after you pull.
As everyone else is pointing out you should probably just pull and then merge the heads, but if you really want to get rid of your commits without any of the EditingHistory tools then you can just hg clone -r your repo to get all but those changes.
This doesn't delete them from the original repository, but it creates a new clone that doesn't have them. Then you can delete the repo you modified (if you'd like).
I came across this problem too. I made 2 commit and wanted to rollback and delete both commits.
$ hg rollback
But hg rollback just rolls back to the last commit, not the 2 commits. At that time I did not realize this and I changed the code.
When I found hg rollback had just rolled back one commit, I found I could use hg strip #changeset#. So, I used hg log -l 10 to find the latest 10 commits and get the right changeset I wanted to strip.
$ hg log -l 10
changeset: 2499:81a7a8f7a5cd
branch: component_engine
tag: tip
user: myname<myname#email.com>
date: Fri Aug 14 12:22:02 2015 +0800
summary: get runs from sandbox
changeset: 2498:9e3e1de76127
branch: component_engine
user: other_user_name<name#email.com>
date: Mon Aug 03 09:50:18 2015 +0800
summary: Set current destination to a copy incoming exchange
......
$ hg strip 2499
abort: local changes found
What does abort: local changes found mean? It means that hg found changes to the code that haven't been committed yet. So, to solve this, you should hg diff to save the code you have changed and hg revert and hg strip #changeset#. Just like this:
$ hg diff > /PATH/TO/SAVE/YOUR/DIFF/FILE/my.diff
$ hg revert file_you_have_changed
$ hg strip #changeset#
After you have done the above, you can patch the diff file and your code can be added back to your project.
$ patch -p1 < /PATH/TO/SAVE/YOUR/DIFF/FILE/my.diff
You can get around this even more easily with the Rebase extension, just use hg pull --rebase and your commits are automatically re-comitted to the pulled revision, avoiding the branching issue.
hg strip is what you are looking for. It's analogous of git reset if you familiar with git.
Use console:
You need to know the revision number. hg log -l 10. This command shows the last 10 commits. Find commit you are looking for. You need 4 digit number from changeset line changeset: 5888:ba6205914681
Then hg strip -r 5888 --keep. This removes the record of the commit but keeps all files modified and then you could recommit them.
(if you want to delete files to just remove --keep hg strip -r 5888
If you are familiar with git you'll be happy to use histedit that works like git rebase -i.
[Hg Tortoise 4.6.1]
If it's recent action, you can use "Rollback/Undo" action (Ctrl+U).
In addition to Samaursa's excelent answer, you can use the evolve extension's prune as a safe and recoverable version of strip that will allow you to go back in case you do anything wrong.
I have these alias on my .hgrc:
# Prunes all draft changesets on the current repository
reset-tree = prune -r "outgoing() and not obsolete()"
# *STRIPS* all draft changesets on current repository. This deletes history.
force-reset-tree = strip 'roots(outgoing())'
Note that prune also has --keep, just like strip, to keep the working directory intact allowing you to recommit the files.