I have many java classes in my local repository and I remember they showed up when I wrote hg status. Now I don't see them anymore although they still exist!
What happened here, and how do I make hg status show them again?
hg status, by default, only shows files that have changed in some way (are new, have been deleted, or have been altered relative to the working copy parent).
From the hg status --help page:
Show status of files in the repository. If names are given, only files
that match are shown. Files that are clean or ignored or the source of a
copy/move operation, are not listed unless -c/--clean, -i/--ignored,
-C/--copies or -A/--all are given.
If you haven't made any changes to your class files, hg status won't list them unless you ask it specifically for the status of that file (hg status path/to/classfile) or ask it to list all files or all clean files (those that are not changed), with hg status --clean.
Related
I know it is strange but I was updating my testcases and thought of removing all the untracked files from the testcase so ran hg purge, but apart from deleting untracked file it deleted tracked files for 230+ testcases too.
Is there any way to revert back to original or can I get the files back? These files are on the server so I can get it by pulling it from server, but this is not helpful as I have to update it again.
If you have modified Working Directory ("modified" by any way) you can easy discard changes and return to the state of clean "."-changeset using
hg up -C -r .
And yes, follow-up to #torek, hg purge must not touch tracked files, because, according to it's wiki
extension purges all files and directories not being tracked by
Mercurial in the current repository
but I can see one possible case, why it's may happen. Next para in description shed some light on topic
With the --all option, it will also remove ignored files
(and some pure speculation below...)
If you had files in .hgignore and added these files into repository by hand (you can hg add ignored files), purge probably may delete these files.
You can (rather easy) verify my idea after returning to good state of repo
Install|add hg-isignored extension (Bitbucket, will disapper soon due to BB-refugee from HG) and check ignorance state of versioned, but deleted by extension files (at least some of) - you'll see result and used pattern from .hgignore
Try (again) hg purge --print in order to get list of purged files. If lists (deleted and ignored versoned files) will have intersections, then you'll get answer on question "Why?"
I can't see any other reasons for such behavior of extension
Can I say "deleting this file is part of this commit" in hg? I know about hg rm, but it seems to only remove tracking of a file, not track its removal.
Concretely, if I have a repository containing file t in two places (A and B), and at A say hg rm t, and commit, and push, and at B say hg pull -u, file t will be there. :-(
I can't imagine anyone wanting that behaviour actually, but that's not the question. The question is: can I somehow sync working trees via hg, or only existing files?
If you pull, the deleted file will be deleted in your history, but not in your sources, locally. You have to update (hg up) for that.
If you have modified this file, and not committed it, Mercurial will tell you that you have uncommited changes, it won't be able to update.
Once it's commited, the deleted file will conflicts with the modified file, you'll be asked either you want to keep the modified file, or delete it.
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..)
How does Mercurial tell a file was modified?
The reason I am asking is because when I run hg status its telling me several files are modified.
However, when I run hg diff there are no changes to report.
I have a theory as why this is happening: (but I am not positive)
I am using NetBeans which has Mercurial support built in. When I edit a file, it shows it as modified, although if I undo (rather than revert) those changes and save it, NetBeans tells me there are no local changes. So I am guessing NetBeans uses diffs to check for modifications while Mercurial is using something else like modification-date.
Is this correct or is something else the cause?
Mercurial does not use modification date to determine the status. This can be verified with a simple experiment:
hg init
echo "This is a test" > test.txt
hg commit -Am "commit"
touch test.txt
hg status
The code which performs the status check is in dirstate.py. If the dirstate is unsure about a file's status (e.g. because only the modification time differs, then it passes it up to localrepo.status for further analysis as seen here.
The hg help status text has some clues that may help:
status may appear to disagree with
diff if permissions have changed or a
merge has occurred. The standard diff
format does not report permission
changes and diff only reports changes
relative to one merge parent.
When you run hg diff, are you specifying any command-line options?
Is it possible the permissions of the file changed? Try hg diff --git which shows the git-style extended diffs that support permissions and binaries. By default hg diff shows only patch-friendly diffs, which don't show permissions changes.
We have a Mercurial repository converted from Subversion a while ago and have today noticed that there are files in the repository that have no history whatsoever.
One of the sympomts of this behaviour is that hg status reports the file as clean, while hg log reports no changesets for the same file:
> hg clone [repo]
> hg st -c FileWithMissingHistory.cs
C FileWithMissingHistory.cs
> hg blame FileWithMissingHistory.cs
FileWithMissingHistory.cs: no such file in rev [...]
> hg log FileWithMissingHistory.cs
> hg log FileWithMissingHistory.cs -f
abort: cannot follow nonexistent file: "FileWithMissingHistory.cs"
> hg log -v | grep FileWithMissingHistory.cs
[gives output, there arechangesets mentioning the file]
Obviously the filenames have been changed in the example. I've tried using hg verify, but this command reports that the repo is fine. Has anyone experienced this and is there anything we could do to bring the history "back to life"? Placing dummy history on the files in question would be acceptable, but suboptimal.
EDIT:
I've done some more investigation and noticed that "FileWithMissingHistory.cs" was renamed from another filename (hg copy + delete) in revision 238. If I do hg update -r238 and hg log on the file at this revision I do not get any history. Doing hg log on the original file reports the history as expected, so it seems that the history is somehow lost during copy (again, the file is renamed using hg copy, and the changeset clearly indicates that the file has been copied).
Sounds strange, actually impossible. What I would try to debug this issue is to update to different revisions and check at which revision the file appears in the working copy the first time. If you do this in a binary search fashion (similar to how the bisect extension works), you should find a revision which introduces the file after a few updates.
This does not solve the problem, but it may help in tracking down its source.
I've finally tracked down the cause of the effects mentioned above and it seems that this is caused by mixed casing issues. Some of the files are located in directories with lowercase names while others are located in the directories with equal names, only that the case is mixed (e.g. "directory/FileWithHistory.cs" and "DiReCtOrY/FileWithMissingHistory.cs"). On Windows, both files will be located in the same directory causing issues.