The mercurial move/rename commands seem to be delete+copy operations, this balloons a repository when binary files are just renamed or moved. With for example
hg mv foo.bin bar.bin
hg rename bar.bin goo.bin
repository now contains 3 identical copies of foo.bin. In retrospect the largefiles extension should be used, but assuming that files are already committed, is there a way to avoid this duplication?
Related
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? :)
I work on Java project. How I can push only source directory without temporary files, build files and project files? I use Mercurial.
Mercurial will only push history, which means that it is only things that you have asked it to track (with hg add) and later committed (with hg commit) that will be pushed.
So like Jim says, you should setup .hgignore file. Do this before adding files to your project and double-check that hg status only lists files you want to add. Then run hg add to add them all.
If you've already put the temporary files and build artifacts under version control, then you can either use hg forget to stop tracking them. You'll still carry them around in the history, so if we've talking about tens of megabytes, then you probably want to re-create the repository.
Create an .hgignore file.
I created a new repository on my local computer, added files and committed giving me the following structure in my working copy:
-/a
-/b
I want to push my initial commit to a remote repository on Bitbucket. I however want to ignore directory b so that it doesn't get pushed. I added
syntax:
glob b/**
to my .hgignore file. The b directory gets pushed anyways.
How can I prevent this?
This cannot be done in Mercurial: you cannot push only an initial version of a file and then ignore later modifications. You can also not push part of a changeset — you either push the entire changeset or not. This way Mercurial makes sure you have a consistent snapshot of your project in all clones.
Preet is correct when he writes that the .hgignore file is a filter for untracked files. The .hgignore file is used to filter the output of commands like hg status and to filter the files added by running hg add with no further arguments.
in .hgignore add:
^b/.*
or b/* if you are using the inferior glob syntax (regex gives you much more control).
The syntax is defined on the first line, and all rules are defined in following seperate lines.
if you want globbing, the first line would be syntax: glob and if regex, the first line would be syntax: regexp (implied by default). Refer to the documentation.
Note that mercurial does not actually push empty directories, so the only way you will be able to test it is if you have a file in b/
I have a git repo at the workspace level. i.e. multiple closely related Eclipse projects in one repo.
If I add .metadata to .gitignore then each time I create new branch and checkout I loose my .metadata file and therefore import all the projects manually. This is unpleasant.
Is it safe to store the .metadata file under version control? This is a multi-developer project and JDK versions and perhaps even OSs (in future) may vary. (We're all on Ubuntu at present.)
Are there any other IDE files which shouldn't be comitted?
Thanks,
Chris.
The problem is that the file and/or directory was already tracked by git before you added it to .gitignore:
for a file, it will continue to be tracked, no matter what;
for a directory, files present in this directory at the time you added it to .gitignore will also be tracked.
This means, among others, that if you have a file f which is untracked in branch b1 but you checkout branch b2 in which this file is tracked, git will remorselessly overwrite f.
As mentioned in the previous question, the solution to make git completely ignore such files after "the harm is done" consists of issuing git rm -r --cached and only then adding them to .gitignore. But this needs to be done branch by branch, which means you will still have the problem in the meantime.
Given your situation, you have two choices:
if you can afford to restart "from scratch", do so and put .metadata immediately into .gitignore -- and commit that first, before even committing the rest;
if you cannot afford that, you have no choice but a git filter-branch.
As to other files to ignore with other IDEs, I can only tell for IDEA: .idea and *.iml. No idea for others...
There are a bunch of file in the history of my hg repo that have been removed. They are causing the repo to get pretty big (several of them are images, and sql dumps from early in the project, among other things that never should have been comitted in the first place).
How do I get mercurial to forget about that stuff and get my repository down to a reasonable size again?
Should I just make a copy of the files (and the .hgignore) and make a new repo, while archiving the old one for future reference?
See:
$ hg convert --help
...
$ hg convert --filemap fmap old new
where file fmap contains something like:
exclude path/to/file/to/purge
(src: https://www.mercurial-scm.org/pipermail/mercurial/2008-August/020721.html)