I performed these steps:
Commited my project
Added a couple class files to my project
Decided I wanted to completely abandon what I had just done
Used TortoiseHg Repository Explorer to Update to last changeset with "Discard local changes, no backup (-C/--clean)" checked/turned on
The two class files I added did not get deleted as I would have expected. They appear in the folder without shell icons.
Questions
Is this correct behavior or a bug?
If this is correct, is there a feature that will allow me to go back to a previous changeset without ending up with a bunch of junk files in my working copy?
Even if you hg add the files, if you haven't committed them, when you update it leaves the files as unknown files. Example:
C:\> md test
C:\> cd test
C:\test> hg init
C:\test> echo >file1
C:\test> hg ci -Am file1
adding file1
C:\test> echo >file2
C:\test> echo >file3
C:\test> hg add
adding file2
adding file3
C:\test> hg st
A file2
A file3
C:\test> hg update -C
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\test> hg st
? file2
? file3
If you enable the purge extension, then hg purge will delete files with ? status. Be careful because files you meant to add to your project but haven't yet will be deleted:
C:\test> hg add file2
C:\test> hg status
A file2
? file3
C:\test> hg purge
C:\test> hg status
A file2
If you don't have added the files to you repository, I think they are not at all under version control. That will also mean they are left alone by the version control system, and you'll have to delete them yourself if you want them to be deleted.
Only if you have actually put them under version control (added them to the repository), you will have to revert your changes, or explicitly delete them from you repository.
The reason for this is of course that you may need some files in your project directory that you don't want to be in your version control repository at all.
Use hg update null on your working folder. Check the docs.
Related
I have a mercurial repo with .hgignore file. I want to remove all files from disk (hg remove) in this repo which match pattern(s) listed in .hgignore.
I can list all ignored files with hg status -i but I don't know how can I delete them.
.hgignore contents:
syntax: glob
build
\.egg*
*.pyc
.DS_Store
*.sublime-*
You can only run hg remove on files that are tracked. To remove tracked files that match the .hgignore patterns, run this command
$ hg forget "set:hgignore() and not ignored()"
This uses a fileset to select the right files.
If you want to remove files that are already ignored by Mercurial (not tracked), then see the purge extension. That can be used to cleanup a working copy so that it looks like a fresh checkout.
From hgrc help
A better example might be:
purge = !$HG status --no-status --unknown -0 | xargs -0 rm
which
will make hg purge delete all unknown files in the repository in the
same manner as the purge extension.
In order to delete ignored files instead of unknown you have ("hg help status") use --ignored | -i option instead of --unknown
I accidentally did a "hg commit --amend" instead of just a commit. How can I roll back the commit to before the amend?
You can use hg reflog (from the journal extension) and hg reset <hash>.
hg reflog -v
should give something like:
<old-hash> -> <new-hash> <user> <timestamp> commit --amend <some-path>
if that is the amend you want to revert, just use:
hg reset <old-hash>
The commit will be reverted to what is previously was and the changes that were amended should now be uncommitted changes (check using hg status and hg diff).
If your version of Mercurial is new enough, I believe you should be able to use the hg unamend command from the uncommit extension that ships with Mercurial. This may require that obsolescence markers are enabled, I'm not sure.
Enable the uncommit extension, add this to your ~/.hgrc:
[extensions]
uncommit =
Actually run the unamend:
hg unamend
Find the latest saved backup in .hg/strip-backup directory
hg unbundle .hg/strip-backup/<latest backup>
Now you should have two heads - one with the amended commit, other one with two commits (first one - old commit before amending, second one caled: "temporary amend commit for (old commit hash)".
if you have histedit extension, you can do hg histedit on it in order to change it (e.g. select edit in order to achieve a state just before the commit, i.e. when you can see all changes using hg diff).
Don't forget to strip the old head.
It's 2022, and my attempts to use hg unamend have not worked. histedit is too clunky for my purposes, but the solution proposed by mariu52 elsewhere on this page can easily be adapted to work without histedit. It relies on the -k option of the strip subcommand.
In a nutshell:
Find the latest saved backup in the .hg/strip-backup/ directory
Run hg unbundle .hg/strip-backup/<latest backup> where <latest backup> signifies the full filename.
Run hg heads and note the rev number corresponding to the amendment.
Let's call this $AMENDREV; this is the rev number we will strip in the next step.
Run hg strip -k --rev $AMENDREV
Using the -k option in the strip command is critical.
WARNING: this procedure will in effect erase the memory of any add or remove commands
that were pending when the amend command was executed.
For example, in the transcript below, the hg add file2 command is effectively
forgotten after the strip command is executed.
For clarity, here's a transcript based on the above recipe.
$ mkdir tmp ; cd tmp
$ ls
$ echo 1 > file1
$ echo 2 > file2
$ hg init
$ ls
file1 file2
$ hg add file1
$ hg commit -m 'one file'
$ hg add file2
$ hg amend -m 'amendment'
saved backup bundle to /tmp/tmp/.hg/strip-backup/d332ee829c21-5a5f23b0-amend.hg
$ hg unbundle -u .hg/strip-backup/d332ee829c21-5a5f23b0-amend.hg
adding changesets
adding manifests
adding file changes
added 1 changesets with 0 changes to 1 files (+1 heads)
new changesets d332ee829c21 (1 drafts)
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
updated to "1a445f3252eb: amendment"
1 other heads for branch "default"
$ hg heads
1[tip]:-1 d332ee829c21 2022-11-09 01:55 -0500 peak
one file
0 1a445f3252eb 2022-11-09 01:55 -0500 peak
amendment
$ ls
file1 file2
$ hg strip -k -r 0
saved backup bundle to /tmp/tmp/.hg/strip-backup/1a445f3252eb-bfaab5ec-backup.hg
$ ls
file1 file2
$ hg list
r0: peak tip 2022-11-09 01:55 -0500
one file
file1
$
hg unamend part of Mercurial 4.5 (2018-02-01).
NOTE: This answer is now deprecated. See the answer from #Sorina Sandu instead.
See hg help commit, where it says:
The --amend flag can be used to amend the parent of the working
directory with a new commit that contains the changes in the parent in
addition to those currently reported by "hg status", if there are any.
The old commit is stored in a backup bundle in ".hg/strip-backup" (see
"hg help bundle" and "hg help unbundle" on how to restore it).
I've a directory in Mercurial repository called httpdocs/css/ui-lightness. I want to move this directory and all its contents to httpdocs/css/jquery/themes/ui-lightness. So, I think this is the command to launch:
hg rename httpdocs/css/ui-lightness httpdocs/css/jquery/themes/ui-lightness
In fact, I've already tried and it seems to work, except that in the working copy the "source" directory (that is, httpdocs/css/ui-lightness) is NOT deleted (while in the repository it is).
Can someone explain why?
A Krtek found, what you're doing should work. Here's me running it locally:
~$ mkdir -p httpdocs/css/ui-lightness
~$ cd httpdocs/
~/httpdocs$ hg init
~/httpdocs$ echo test > css/ui-lightness/file
~/httpdocs$ hg commit -A -m "initial commit, old location"
adding css/ui-lightness/file
~/httpdocs$ hg rename css/ui-lightness css/jquery/themes/ui-lightness
moving css/ui-lightness/file to css/jquery/themes/ui-lightness/file
~/httpdocs$ ;s
bash: syntax error near unexpected token `;'
~/httpdocs$ ls
css
~/httpdocs$ tree
.
`-- css
`-- jquery
`-- themes
`-- ui-lightness
`-- file
4 directories, 1 file
~/httpdocs$ hg stat
A css/jquery/themes/ui-lightness/file
R css/ui-lightness/file
If you have any untracked (possibly ignored) files in httpdocs/css/ui-lightness they won't be renamed and thus the directory won't be empty and thus not removed, but the tracked contents in that directory should be moved.
Notice I've not yet committed that rename (and that it shows up as an Add and a Remove even though Mercurial knows it's a rename), but for it to be reflected in other clones, I'd need to hg commit, hg push and they'd have to hg pull and then either hg update or hg merge.
What are you calling the "repository" and the "working copy" and where do you do your hg rename command ?
I think you just forgot to push your changes on one side and then do a pull on the other side. Changes won't magically appear in all the clones of your repository, you must retrieve the changes.
I just tested, hg rename removes the files just fine.
It does not delete the source, it just marks it for removal in the repository. You should remove files by hands afterwards.
In our repository we have initial version of database (binary file).
I have executed hg pull and I saw that someone committed another version of this file.
As I won't to loose my changes in dev db, I did make a copy of it (copy file.db my_file.db) in same directory.
When I runned hg up, mercurial overwrited file.db with new version and deleted my_file.db!
I'm on windows 7 x64, and tried various software that recover deleted files, but with no success.
How can I get back my version of file.db or recover my_file.db? I didn't commit it.
I really don't think mercurial deleted your untracked file. Here's the sequence you've described as I understand it:
ry4an#four:~$ mkdir zote
ry4an#four:~$ cd zote
ry4an#four:~/zote$ hg init orig
ry4an#four:~/zote$ echo text > orig/file.db
ry4an#four:~/zote$ hg -R orig commit -A -m 'initial'
adding file.db
ry4an#four:~/zote$ hg clone orig clone
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#four:~/zote$ mv clone/file.db clone/my_file.db
ry4an#four:~/zote$ echo more text >> orig/file.db
ry4an#four:~/zote$ hg -R orig commit -m 'new line'
ry4an#four:~/zote$ hg -R clone pull
pulling from /home/ry4an/zote/orig
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
ry4an#four:~/zote$ hg -R clone update
remote changed file.db which local deleted
use (c)hanged version or leave (d)eleted? c
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#four:~/zote$ ls clone/
file.db my_file.db
ry4an#four:~/zote$ cat clone/my_file.db
text
ry4an#four:~/zote$ hg -R clone status
? my_file.db
You can see that afterward my_file.db is still there. Even with --clean as Mikezx6r mentiones the file is still there:
pulling from /home/ry4an/zote/orig
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
ry4an#four:~/zote/clone$ hg update --clean
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
ry4an#four:~/zote/clone$ ls -l
total 8
-rw-r--r-- 1 ry4an ry4an 15 2011-02-08 14:31 file.db
-rw-r--r-- 1 ry4an ry4an 5 2011-02-08 14:28 my_file.db
ry4an#four:~/zote/clone$ hg stat
? my_file.db
ry4an#four:~/zote/clone$
It's not what you want to hear, but it's much more likely you accidentally botched the 'mv' and only thought you created the copy or somehow externally deleted it. Or your antivirus app saw a pattern it didn't like a refused to create it, or some other horrible, accidental thing.
It's also not helpful now, but this is a great example of why you should commit early and often, and especially before updating -- it's just too easy to make mistakes, but once something in in the repo there's nothing you can do to accidentally remove it.
I'd like to remove a directory and all the files in it from a repo.
I have removed all the files with hg remove, but how do I remove the directory itself?
Will it just automatically vanish once I commit all the removed files?
Yes. Because mercurial doesn't track directories at all, only files, it only creates directories that have files in them, and if someone hg updates to a revision any directories that become empty are automatically removed. So if you do:
hg remove directory/*
hg commit -m 'removed all files in directory'
hg update -r 0 # updates to a different revision
hg update tip # jump back to the tip
That last update would remove the directory. For everyone else it's even easier. When they hg update to your new changes their directory will just vanish (provided they have no uncommitted file in it).
hg remove dir
If you end up with empty directories and you want to get rid of them, an easy way is the purge extension. (add purge= under the [extensions] group in your .hrgc file to unlock).
You can then use
hg purge
to clean up the empty dirs... You must be careful with the purge command as it removes everything that is untracked in your repos. I strongly suggest you run a
hg purge -p
beforehand to see what the command will do ( -p will print a "test run" without doing anything.) Never forget the --help option! ;)
edit: I prefer using purge to hg update in succession as updating triggers rebuilds in my IDE if it is open (and it's a good bet it is when I do that). hg purge will probably be smoother. And you can use --all to include ignored files too (must be careful though).
To remove a directory, Just do
hg remove <dir>
hg commit -m "..."
This will remove the directory and all files under it.