I'd like to know if there are any consequences when deleting a tracked file from file system (e.g. via windows explorer) in comparison with when using hg remove to delete it from file system and untrack it.
In both cases, I'll commit afterwards, just in the first case tortoise HG marks the file as missing with exclamation mark, with the second it marks it as clean and ready for removal.
Besides this are there any differences?
If you go the file system path and don't make any other changes to tracked files, hg will give you an error when you try to commit:
nothing changed (1 missing files, see 'hg status')
(This is just a special case of nothing changed.)
If you have changed something else, hg won't complain at that point, but the file's status will continue to show up as missing with hg status. This has the negative effect of cluttering up your (mental) workspace and making it harder to tell at a glance what your working directory's current status is. Moreover, the file remains in the repository and will be restored by hg update for any revisions where it is still being tracked!
hg remove will return an error if the file was already deleted from the filesystem; in this case you should use hg forget to tell Mercurial to stop tracking the file.
If you prefer doing big changes with external utilities (like Windows Explorer), you can use the nifty hg addremove which automatically detects additions and removals. (The downside is that you might remove and untrack accidentally deleted files.)
Related
Accidentally i hg added several binary compiled files from a project along with tons of little changes on several files.
my hg status now show that i have a dozen files modified (correctly) and two dozen files added (mistake).
how do i undo that?
Most answers here tell me to install the MQ extension or to use rollback, but the manual for MQ ext says that i'm not really supposed to use it and that there are (slightly more complicated) ways of doing the same MQ does with mainline hg -- though it fails to show how. and rollback shows warnings about not being supposed to be used because it is deprecated.
So, how do i remove from my upcoming commit the files added by mistake, while keeping the modified files that i want to commit?
When you added (instead of modified) the files accidentially use hg forget FILENAME instead of hg revert FILENAME.
You can revert those files. hg revert fileyouwanttorevert otherfileyouwanttorevert
Okay, so I really got ahead of myself here.
After moving a number of files around, renaming some, and deleting a bunch more, I ended up with a large number of files in hg status with an exclamation point (along with numerous question marks). I ran hg rm -A to remove all the files that no longer existed.
Then I realized I should have used hg addremove to track the files that were just moved, not deleted. Oops.
But I hadn't committed anything yet, and hg status showed all those "missing" files with an R now. So I ran hg revert thinking that would restore everything to the way it was. I could even see where it said Undeleting file /path/to/xyz for each file that I wanted to restore (I wasn't worried about restoring the files themselves, of course, just the file paths).
But instead of a big list of files with exclamation points, those "removed" file references are simply gone. They're not listed in hg status, they're not in the file system (obviously), and they're not listed in any recent commit.
What's going on here?
Why would all those file references just disappear from the repo without a commit?
How can I get those file references back so I can actually track them like I wanted to?
I'm pretty rusty with DVCS, I guess. I realize now I should have been using hg move for these operations, but that doesn't help my current situation, does it? :)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do I return to an older version of our code in Subversion?
I was looking at the diff in the commit window on Eclipse (with subclipse) and tried adding a line (by hitting enter) but instead committed by changes without a comment and without me making sure I wanted to commit the things I changed.
This added a commit with no comment and with changes I wasn't sure of to the remote repo. I checked out the previous revision and committed those changes over the commit I made accidentally.
So now HEAD is the same state as the revision before my accidental commit, but I would like to properly commit my changes now. I'm not sure how, though. When I switch to the accidental revision (to get my changes back), it doesn't let me commit because it says nothing was changed. I'm guessing it's comparing my local files to the revision I checked out, but I need it to compare it to HEAD.
What can I do here?
You could (svn) export your accidentally committed revision over your working copy. Then you can make your adjustments and commit your changes.
On the command line:
svn export -r <your accidental commit> <working copy directory>
In Eclipse:
right click on the accidental commit in the history view
select "Export..." and choose the directory containing your working copy
The easiest thing would be to make a unified diff of the revision you committed and then use the Apply Patch option to reapply it to your workspace.
You can also just do Show History on the changed file. Then find the revision, select the file in the appropriate pane, and choose the Get Contents option. This will make your working copy version of that file match the contents of that file in the selected revision.
In either case, your working copy should now show as dirty and you can review and commit when ready.
I ended up reverting the changes from the very last commit I made and then re-committing those after checking everything.
I'm seeing something I don't expect in my Mercurial repo. A change that has been made in a branch is showing up in default. There is no changeset in the log, merge or otherwise, accounting for the change moving into default from the branch.
I checked the basics: I'm in default, did an 'hg pull', 'hg update -C', 'hg purge', and an 'hg st' which came back clean.
If I look at the file locally the change I am expecting is not there. If I do an 'hg diff -r ' then it tells me that my local file is missing the change I expect to see. The file does not show as modified in 'hg st' and a simple 'hg diff' on it shows no differences.
I would expect that whenever doing a diff with an unmodified file explicity against the last changeset in whatever branch I'm in with '-r' it should come back with no differences. Am I wrong? Am I misunderstanding this basic concept?
Thanks,
Scott
I think hg has an internal cache of which files it thinks are modified, and somehow this has got out of sync. This happened to me before, but I can't remember whether I deleted the file first or just used hg revert.
I want mercurial to remove several files from the current state of the repository. However, I want the files to exist in prior history.
How do forget and remove differ, and can they do what I want?
'hg forget' is just shorthand for 'hg remove -Af'. From the 'hg remove' help:
...and -Af can be used to remove files
from the next revision without
deleting them from the working
directory.
Bottom line: 'remove' deletes the file from your working copy on disk (unless you uses -Af) and 'forget' doesn't.
The best way to put is that hg forget is identical to hg remove except that it leaves the files behind in your working copy. The files are left behind as untracked files and can now optionally be ignored with a pattern in .hgignore.
In other words, I cannot tell if you used hg forget or hg remove when I pull from you. A file that you ran hg forget on will be deleted when I update to that changeset — just as if you had used hg remove instead.
From the documentation, you can apparently use either command to keep the file in the project history. Looks like you want remove, since it also deletes the file from the working directory.
From the Mercurial book at http://hgbook.red-bean.com/read/:
Removing a file does not affect its
history. It is important to
understand that removing a file has
only two effects. It removes the
current version of the file from the
working directory. It stops Mercurial
from tracking changes to the file,
from the time of the next commit.
Removing a file does not in any way
alter the history of the file.
The man page hg(1) says this about forget:
Mark the specified files so they will
no longer be tracked after the next
commit. This only removes files from
the current branch, not from the
entire project history, and it does
not delete them from the working
directory.
And this about remove:
Schedule the indicated files for
removal from the repository. This
only removes files from the current
branch, not from the entire project
history.
If you use "hg remove b" against a file with "A" status, which means it has been added but not commited, Mercurial will respond:
not removing b: file has been marked for add (use forget to undo)
This response is a very clear explication of the difference between remove and forget.
My understanding is that "hg forget" is for undoing an added but not committed file so that it is not tracked by version control; while "hg remove" is for taking out a committed file from version control.
This thread has a example for using hg remove against files of 7 different types of status.
A file can be tracked or not, you use hg add to track a file and
hg remove or hg forget to un-track it. Using hg remove without
flags will both delete the file and un-track it, hg forget will
simply un-track it without deleting it.