I've got a configuration file ("config") that we originally committed to our repository. (first mistake)
We then deleted that file using hg rm, and left a sample configuration file in the repository.
When developing, we just copy the "config.sample" file to "config". However, whenever I update to a different branch and back to the branch with the delete, the untracked config file is deleted.
I've already added the config file to .hgignore.
Is there a way to make mercurial allow the existence of this untracked file going forward?
It looks like the branch you go to before coming back contains a config file too. When updating back, the file was deleted, so mercurial removes it.
Try deleting the config file in your other branch, too, and adding the file in the .hgignore of that same branch.
Related
In my repository somebody committed files that should be unknown (or ignored, according the .hgignore file).
How can I tell to Mercurial to no longer track those files but leave the files as unknown (or ignored) on remote working copies? (With remote working copies I mean working copies of the other users of the repository.)
More details: Specifically those files are .classpath and .project generated by Eclipse IDE when the project was imported as Maven/Gradle project. They have been added to the repository and committed. I want to do not track changes of that files but I don't want to ask everybody to re-import the project into Eclipse again. Renaming .classpath and .project to .classpath.template and .project.template does not resolve my issue.
That is tricky, as the file will be stored as deleted in the changelog when you tell hg to forget it - and on update it will be deleted in the working dirs of everyone who pulls and updates to a rev later than the one where those files have been removed from tracking.
If you can get by with everyone using hg revert -rTRACKED FILENAME where TRACKED is the changeset where the files are (still) tracked, it is not really nice but probably the easiest solution.
You might want to add all files you do not want to be ever tracked to add to your .hgignore so that these won't be added by hg addremove accidentially.
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.
When trying to export a patch for a commit, the resulting patch file doesn't include empty files that were added in the commit.
Steps to reproduce:
Create a new folder and initialize it as an Hg repository.
Add some zero-byte file to that folder, and create an initial commit for that file.
Create a second zero-byte file, and create a second commit for that file.
In Hg Workbench, right-click on either of those commits, and choose Export >> Export Patch.
Open the resultant patch file in Notepad / any text viewer.
Observe that the patch file does not contain any information about the new files that were added.
It seems like the newly added files should be included. If I exported that patch and someone else applied it, they wouldn't really be getting the full changeset, since the new files aren't included.
Can someone tell me what I'm doing wrong, or why it behaves this way? This is not the behavior I expected.
I'm using TortoiseHg 2.7.1, which includes Mercurial 2.5.2.
I enabled the largefiles extension, committed a file and pushed it. I need to permanently revert this change. How can I do it? Is there a way to make this permanent?
If you're added the file like this
$ hg add --large my-file
then Mercurial will have committed a file called .hglf/my-file to the repository (the so-called standin file) and it will have pushed my-file to the remote server when you pushed your commit.
If you disable the largefiles extension, then all there is left in your history is the .hglf/my-file file. You can delete this file like normal with
$ hg remove .hglf/my-file
The standin file will still be present in the history, just like any other file Mercurial has been tracking. But the large file (my-file) is not part of the normal Mercurial history and so you wont see it in new clones where you haven't enabled the largefiles extension.
I am trying to pull some files and directories and I am having the following messages:
When I look in my repository I can see that the files have been downloaded but all contains _ as prefix, and even the names of files and folders contain _
requesting all changes
adding changesets
adding manifests
adding file changes
added 1094 changesets with 4304 changes to 1071 files abort:
untracked file in working directory differs from file in requested revision: '.hgignore' [command interrupted]
What is wrong?
I think you have created a .hgignore in your working directory without adding it to the repository (hg add). This file is "untracked".
Someone else, from another clone, has added this file too, committed and pushed it. Now, when you try to update your working directory, Mercurial try to add this file but sees a file with the same name in your working directory which is untracked and different.
There's two solution to your problem :
Backup your .hgignore file, do the update and add the differences from the backup if necessary
Add your own file to the repository with hg add, then re-run the update. It will maybe be necessary to commit the file prior to the update.
I'll advise using the first solution.
When you say the files in the repository have _ as a prefix, you're looking down inside the .hg directory aren't you? That's the data store for Mercurial itself and the files in there are revlogs, not your files. Outside of .hg you'll have a working directory where the files are the actual files you expect. You're not getting one of those now because hg update is refusing to update the working directory because doing so would overwrite your uncomitted .hgignore file.
What exact command are you running? It looks like it's doing a hg pull followed by an hg update so I'd guess hg clone but if you already have a .hgignore lying around that's not the right command to use. If instead you're using hg pull -u or hg fetch you should just use hg pull instead to get the changesets. Then you can:
hg add .hgignore # add the hg ignore file you already have that's untracked
hg commit -m .hgignore # commit the .hgignore file you just added
hg merge # merge your new commit (.hgignore) with the changesets you just pulled down.