When I run hg outgoing -v I see the outgoing changeset and all files it includes. I forgot to set Mercurial to ignore images, and I've realised that my outgoing contains images. I'd like to remove all .jpg files from outgoing.
I did another hg commit after the one that added the images, so hg rollback doesn't seem to be an option. I've tried running hg push, but I aborted since it took too long to finish (because of the images). Can I fix this without starting the repository again?
Yes. In your case, the most simple approach is probably:
Don't panic. If anything goes wrong, try the following steps again :-)
Clone your repo locally (just use the broken version as "url") and use -r to get everything but the commit that you don't want. You can use hg log on the new repo to make sure you have what you want.
Make sure the images don't get committed -> edit .hgignore, etc.
Commit that
Export the last commit (use hg export -r ...) and apply it to the "good" clone (hg import)
Move the broken repo somewhere else (just in case you still need it)
Continue to work on the new, clean copy. You might need to add the default push path to hgrc again. Just compare the content of the .hg/hgrc files of your broken and good repo.
Related
I have a commit onto which I have amended some files. Some of these files that were part of the amend I do not want in this commit. Is there a way in Mercurial to remove certain files from the commit without losing the changes I have made to them? Thank you.
Steps:
Made some changes
hg commit -m
Made some more changes (some of these file accidentally amended)
hg amend
Try out:
hg forget somefile.txt
hg commit --amend
If the file was new (i.e. you had used hg add).
If that file already existed try:
cp somefile.txt somefile.txt.bak
hg revert somefile.txt --rev .~1
hg commit --amend
Which is basically telling mercurial to revert the file (somefile.txt) back to the state it was one revision ago (--rev .~1).
Just make sure to back up the file you are reverting before entering the command so that you do not lose your changes. I was under the impression mercurial does this automatically for you, but after testing it quickly I'm not so sure.
hg uncommit somefile.txt does exactly this for me.
Like plain git reset, it removes the change from the commit but leaves the file contents unchanged, so now hg diff shows the change you just uncommitted.
The uncommit command claims to come from the uncommit extension, but may actually be coming from the evolve extension, I admit I'm not 100% sure!
Say I type hg add in Mercurial, and there a bunch of untracked files in my working directory that are not ignored. What is the easiest way to un-add all those files without explicitly typing the name of each file?
Can I just un-add them all with one command?
Preface
You must always ask questions, which contain as much information as possible. Because now your question, depending from some conditions, may have totally different answers.
Case One - no local modifications in already versioned files, only added (and not committed) files
hg revert will return your working directory to the state after the last commit, undoing all changes it it.
Case One - local edits, which you want to save and occasionally added files
Read about filesets in Mercurial.
Use fileset in the hg forget command, something like hg forget "set:added()".
Use hg revert or hg forget on the files (both do the same for a file you ran hg add on). To avoid typing out the filenames, you can use a fileset like this:
$ hg revert "set:added()"
This will revert the file back to how it looked in the working copy parent revision, i.e., it will become unknown again.
hg revert -r .^ path-to-file will revert the commit from the commit-set.
then commit and submit (if using jelly fish) and you'll see the files removed from the changeset. I don't know why .^ works yet, but somebody will probably know.
You could always just re-clone your repository and then replace (delete existing and then copy new) the .hg directory in your working folder with the one from the fresh clone... (assuming you have no pending commits..)
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
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.
Being very familiar with the subversion workflow and that fact that 99.9% of the time my computer is connected to the internet, I don't like doing 'hg ci' and 'hg push' separately.
I remember bzr had a 'checkout' command that would bind subsequent 'commit' commands to automatically commit directly to the server ('push').
Does mercurial have something similar to this?
PS: Writing a shell script or alias that runs 'hg ci $* && hg push' would be the last thing I'd do.
You could add a hook to run push after a successful commit.
EDIT: I just tried it out and it seems to work fine. I added the following to the .hg/hgrc file of the repository I wanted to activate automatic pushing for:
[hooks]
commit.autopush = hg push
EDIT 2: Also, you don't have to worry about something like this:
You're in a repository that you don't want to automatically push.
You use hg -R ~/another-repo-that-autopushes commit to commit in a different repo that does automatically push.
Will the hg push hook end up pushing the changes in the current directory instead of the one you're committing in?
No, it won't. According to the page I linked:
An executable hook is always run with its current directory set to a repository's root directory.
It's an edge case, but Mercurial handles it correctly.