It seems like ShelveExtension only shelves your modified files leaving untracked or deleted.
I am new to Mercurial and coming from git so for me this is not expected.
Even bigger problem I am not able to hg unshelve with what I assume is an error message.
See below:
unshelving change 'main'
temporarily committing pending changes (restore with 'hg unshelve --abort')
rebasing shelved changes
abort: uncommitted changes
Is that an expected behavior and I am just missing something?
How could I unshelve my modified files without restoring/committing/etc.?
Is there an extension which behaves exactly like git stash?
Steps to reproduce:
Environment:
OS: Windows 8
Mercurial: Mercurial Distributed SCM (version 3.0.1).
Installed as cygwin /usr/bin/hg (Tortoisehg is not installed, Windows hg is installed but not used)
Extension: ShelveExtension.
Is that an expected behavior and I am just missing something?
Yes, this is normal behavior. You need to do hg addremove (or manually hg add and hg rm the individual files) if you want Mercurial to track file creation and deletion. Renaming should be done with hg mv. This is vaguely similar to git add, except that you do not need to do it for modified files.
When you unshelve, your working directory should be clean. At the very least, it should not have any missing files (prefixed with ! in hg st) nor any modified files (prefixed with M). You can always make a temporary commit and hg strip it later.
How could I unshelve my modified files without restoring/committing/etc.?
There's no sane way to do this in the general case. What if the shelf contains changes to a file which no longer exists? If the file deletion had been committed, you could generate a patch conflict, and that's what Mercurial does. But without a commit to conflict with, there's no obvious response to this situation.
Is there an extension which behaves exactly like git stash?
Not to my knowledge, but this is beyond the scope of StackOverflow.
Occasionally when performing a rebase using the MercurialEclipse plugin my repository gets thrown into an odd state. It will become stuck in a "rebasing" state, yet when I try to abort the rebase (e.g. "hg rebase -a") I get this error message:
abort: unknown revision 'xxxx'!
Where xxxx is a revision hash. Usually at this point I've abandoned all hope of performing the rebase -- I just want to get back to a happier time when my repository was not screwed up. So far my solution has been to nuke my project directory and clone it again. Is there a less drastic solution?
Just remove the .hg/rebasestate and your repo will work.
The patch described in this thread calls the internal function clearstate which just unlinks this file.
In situations similar to this, I usually do:
$ hg check
$ hg verify
$ hg up -C default
Instead of default, use whatever branch you're working on. This takes time, but so does re-cloning the repo.
It usually helps.
I want to completely delete a Mercurial commit as if it was never entered in the repository and move back to my prior commit.
Is this possible?
If it was your last commit and you haven't pushed it anywhere, you can do that with rollback. Otherwise, no. Not really. Time to change your passwords.
Edit: It has been pointed out that you can clone from an older revision and merge in the changes you want to keep. That's also true, unless you have pushed it to a repo you don't control. Once you push, your data is very likely to be very hard to get back.
You can try to remove mq info about your commit.
For this you need to go File->Settings->Extensions.
There check mq and restart gui.
After that just right click on unneeded commit and
ModifyHistory->Strip
To edit the history I would use the Histedit Extension extension.
hg histedit 45:c3a3a271d11c
However keep in mind this only makes sense in a situation where you have not yet pushed the commits to the public repository, you own the public repository and/or you can account for all the clones out there. If you receive the following error:
abort: can't rebase immutable changeset 43ab8134e7af
It means that Mecurial thinks this is a public changeset (see phases) that has already been pushed - you can force it to be a draft again doing:
hg phase -f -d 45:c3a3a271d11c
I encounter this fairly often. I make a commit and then pull to push. But then there is something incoming that makes my newly made commit unnecessary. A plain hg rollback isn't enough because it only undoes the pull...
This is the thing to do:
hg strip <rev>
Things are painless when you don't push your changesets anywhere.
If it's more than one commit and/or you already pushed it somewhere else, you can clone your repository and specify the last changeset that should be cloned.
See my answer here how to do this:
Mercurial: Fix a borked history
If you only committed locally and didn't push, you can just create a clone locally (as described in my link) and you're done.
If you already pushed to some remote repository, you would have to replace that with your clone.
Of course it depends if you are able (or allowed) to do this.
You can use "hg backout" to do a reverse merge basically. All options are discussed in the freely available book "Mercurial: The Definitive Guide":
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
If using tortoise you can use modify history > strip...
Yes. Unless I am mistaken, as of v2.3 (rel. 2012/08/01) you can use the HisteditExtension with a drop command to drop a commit, along with strip or backout to remove changes.
A simple Google search on the feature: https://www.google.com/webhp#q=histedit+drop
In 2022 I do use evolve extension. It is one of the best extensions for this purpose.
To prune unwanted changeset, if you for example did a quick hack to get the code working:
$ echo 'debug hack' >> file1.c
$ hg commit -m 'debug hack'
Now you have a proper patch you can do hg prune .:
$ hg prune .
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
working directory is now at 2a39221aaebb
1 changesets pruned
If you push the change to the remote repository you will find only obsolescence markers:
$ hg push
searching for changes
no changes found
remote: 1 new obsolescence markers
To check the changes to your local repo you can pull from the remote one:
$ hg pull
pulling from ssh://userid#server/repo
searching for changes
no changes found
Merging in my Mercurial repository is not working like I expected.
Several days ago I started work on a feature then realized I could not finish it before sprint end. I updated back to the point in time that I started work and continued from there (effectively creating a branch). Now I am ready to merge the changes from that branch back into the tip, yet for some reason when I merge nothing happens. TortoiseHg says the merge went fine, and both the tip and the changeset that I'm trying to merge from are bold in the Repository Explorer but none of the changes from the branch are in my working directory.
Here is a video of the unexpected behavior: http://screencast.com/t/ZTQ0ZjU1NTM
Notice that when I go to commit there are no changes detected. In what way is this a merge?
Am I missing something? Is Hg broken? I could've sworn that I've done this before and it went off without a hitch.
Can you try it from the command line?
hg update -r48
hg merge
hg commit -m "merged"
I've just recently moved a lot of my Views and Controllers into more appropriate locations and am now wanting to pull down recent changes from our central repo.
I've done a hg pull which worked fine and asked me to do a hg update to bring the changes down locally. This in turn informed me that I needed to do a hg merge however when I try this, I get a message stating that
abort: outstanding uncommitted changes
When I check this using hg status I see in the list all of the files that I've moved (so they're now deleted from their old location).
How do I tell Mercurial that I've removed these files? Do I have to go through each one of them and manually do a remove? Is this something that's possible using only the command line rather than doing it with a GUI tool?
From the command line to automatically hg rm the files you've removed you'd:
hg addremove
It's likely your GUI (you didn't say which you use) exposes that functionality too.
However, that's not what's causing your message. You have some already made local changes that mercurial does know about (unlike the removed files which it doesn't know about until you tell it), and you need a hg commit before you can merge.