How to move files (to subfolder) without losing their history?
In my Mercurial repository (I mean the folder with the .hg in it) I have MyProject/ folder with all project files. Now I need to create src/ folder inside and move all files to it (from MyProject/ to MyProject/src/). How can I do it without losing all history?
Since you have a "tortoisehg" tag, I figured I'd explain the way I do this using the GUI.
Usually, I just rename/move files in my IDE, or from windows explorer, then when I go to commit, THG will show a bunch of (?) unknown files and (R) removed files. Just right click on any of the files and choose "Detect Renames...", then click the "Find Renames" button.
You might have to adjust the "Min Similarity" slider until you get all the files you want and only the files you want, but it's usually very straightforward.
hg mv
does do the right thing, but hg log does not list entries past the move unless you
give it the -f option. See this question for more info
Why 'hg mv' (mercurial) doesn't move a file's history by default?
After you do this, you likely want to add the -f option to hg log
to the hgrc file for the repo.
.hg/hgrc
[defaults]
log = -f
In Windows with Tortoise HG installed, there is a windows shell extension that handles this very nicely.
In Windows Explorer, simply right-click and drag the file(s) you wish to move into the destination folder. You are then presented with a pop-up that give you these choices:
HG Move versioned item(s) here
HG Copy versioned item(s) here
Use hg mv to move your files and then use hg log -f (follow) to see history including renames.
Related
I have accidentally run hg strip, and deleted a stack of commits. I have not done anything in the repo since. Is there a way for me to bring back this stack of commits, to undo the hg strip I just ran?
As long as you didn't run the strip with the --no-backup option, the stripped changesets can be found in the repository under .hg\strip-backup. If you sort the directory content by date the latest one is likely the one you need to restore. Restore it with hg unbundle <filename>.
It is possible to hg pull from a strip backup file as an alternative to using hg unbundle.
As noted in a comment on another answer to this question, hg unbundle has fewer options and only works with bundles, but can unbundle more than one bundle at a time. Whereas hg pull can pull from a single source (share/web/bundle) and has other options.
Here's an example of using hg pull based on an external post by Isaac Jurado:
Usually the backup is placed in REPO/.hg/strip-backup/. See the
example below:
$ hg glog
# changeset: 2:d9f98bd00d5b tip
| three
o changeset: 1:e1634a4bde50
| two
o changeset: 0:eb14457d75fa
one
$ hg strip 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
saved backup bundle to
/Users/hchapman/ttt/.hg/strip-backup/e1634a4bde50-backup.hg
And then, what one would do to recover those changesets would be:
$ hg pull $(hg root)/.hg/strip-backup/e1634a4bde50-backup.hg
Here is a worked example of unbundle from an external post. I've cleaned it up slightly to make it a little more general:
Recovering stripped files when using Mercurial
If you accidentally strip a patch and do not have a backup for it, you
can still recover your files using Mercurial. To recover your files:
Open a Microsoft Windows Command Prompt window.
Navigate to the project folder where you stripped the files.
Run the dir command
Navigate to the .hg folder where Mercurial stores all relevant project
files.
Run the dir command again.
Navigate to the strip-backup folder where Mercurial stores the backup
bundles of stripped patches.
Run the dir command again. Multiple files display in the directory
that use the <hash>-hg format. They are the backup bundles of stripped
patches.
Use Windows Explorer to find the required file. Open the strip-backup
folder in Windows Explorer, and sort by Date modified descending.
Unless the necessary backup bundle is already known, [it is recommended to]
restore the bundles in reverse chronological order starting
from the most recent bundle.
Navigate back to the project folder.
To restore a bundle, run hg unbundle .hg\strip-backup\<bundle_file_name>. ... You may want to add it to the
PATH environment variable to make it accessible globally.
Synchronize the project [using hg pull] to see the restored patch. If
the restored patch is not the one needed, then continue restoring the
patches in reverse chronological order until the required patch is
retrieved.
Note: You may restore the backup bundles in any order, instead of
using reverse chronological order. However, it may not be safe to do
so. You may end up attempting to restore a backup bundle, which has a
dependency on another backup bundle that has not been restored. In
this case, you will get an error.
As a user of TortoiseHG, I have been wondering how the thg drag_move command works which mimics (or implements) the functionality behind the "HG Move versioned item(s) here..." context menu entry.
The help entry obtained via thg -v help drag_move gives:
thg drag_move SOURCE... DEST
move the selected files to the desired directory
As far as I understand, it must execute the following sequence (or similar) under the hood:
hg forget SOURCE
mv SOURCE DEST
hg add DEST
But if I do that manually (outside of TortoiseHG), it (naturally) doesn't associate DEST with SOURCE, it rather treats them as individual, unrelated changes.
If I use the GUI or the thg drag_move command, it keeps the history of these entries the same, at least within TortoiseHG I can still see SOURCE's history when I look at DEST's history after the move.
Is this a TortoiseHG extension to Mercurial or is there a hg option to achieve the same "natively"?
TLDR: You can use hg move OLD NEW to achieve the same functionality as thg drag_move.
Thg is using hg move under the hood when it's doing drag_move (see the run.py and quickop.py sources for details).
Hg move is the right way of renaming or moving a file in Mercurial because it's tracking the operation, as it says in his help message (hg help mv):
rename files; equivalent of copy + remove
Mark dest as copies of sources; mark sources for deletion. If dest is a
directory, copies are put in that directory. If dest is a file, there can
only be one source.
So I have a directory called flash. I'd like to move it totally from an existing Mercurial repo located at ~/wdm to another existing Mercurial repo, located at ~/wdm-js.
I've been told this is possible with hg convert, but I don't really know how this works. I have tried the following, but think I may have got something wrong.
Having read up on the hg convert for Mercurial docs, I've created a filemap, which reads as follows:
include flash
Then I've gone to ~/wdm and run the following command:
$ hg convert . ~/wdm-js --filemap ~/filemap.txt
I've seen a load of output as follows:
scanning source...
sorting...
converting...
413 [doc/design][m]: first stab at a design doc for model (sent to list).
[412 more history items]
So this looks fairly promising. But when I look at wdm-js there is no flash directory there. And none of the flash directory files have moved from the wdm directory. And the hg status of both repos looks no different.
Do I still have to copy the flash directory across manually, and hg add/hg remove all the files manually to both repos?
Or... should this have been done for me, meaning that I have messed up in some way?
hg convert doesn't update the working directory in the destination repository (it leaves it at the original null revision), so do a hg update there to see the files. Also, the way you ran it, it copies the files; you can either delete them from the original repository via hg forget or hg remove, or use hg convert again using a filemap with the line:
exclude flash
To copy into existing repository you need first copy flash folder into new repository as you did it with convert command and then push the changes from new repository into existing target repository.
When I started my Mercurial project I forgot to exclude everything under my target/classes directory, such as:
target/classes/com/mypackage/MyClass.class
Now these binary files are causing conflicts when I do a hg update.
Is there a single command that would allow me to delete all of these files from the entire project history?
Or, if not, is there a command that would allow me to remove them one file at a time?
If you just want to remove files from last revision, remove files from disk and use hg addremove or hg remove --after target/classes/com/mypackage/*.class to inform Mercurial about your deletion.
If you want to permanently remove all class files from you entire history use hg convert and --filemap option to rewrite your repository and get rid of files from all revisions. However this solution alters revision ids. In multi user environment it may cause some problems because it creates a new repository effectively.
If you delete the files in question then do hg addremove then the files will be removed from the repository. However they will still be in the history though, but is that really a problem?
Use hg remove --after target/classes/com/mypackage/*.class. (--after will avoid deleting the on-disk files).
So I accidentally included a config file (different for each machine) into our mercurial repositories.
How can I get Mercurial to not include it in version control? I don't want to delete the file since I still want it. And I don't want to cause the file to get deleted on other developer's working directories either.
And how do I do this in TortoiseHG?
Right click on the file -> TortoiseHG -> Forget Files. Click Forget. Commit and Sync.
Edit:
You'll also want to add the path to your .hgignore to keep it from getting added again. You can right click on the file in the HG Commit dialog and choose to ignore it.
Here's the manual way of doing it through the command line:
Copy the config file somewhere outside of the repository.
Run hg rm path/to/config/file
Add the config file path to your .hgignore.
Commit the repository.
Move the config file back to where you had it.
Do an hg stat on your repository to double check you did everything right. (It shouldn't show up in the list of modified/added files).
Edit:
hg forget is the best way to do this.
Run hg forget path/to/config/file
Edit your .hgignore and add the path to the config file.
hg ci to save your changes.
Run hg stat to ensure everything worked according to plan.
See nates answer for how to do it TortoiseHG.
hg remove or hg remove -f?
I think hg forget also removes it from the branch.
In both cases, files are retained in your directory.
For those using SourceTree, there is an option Stop Tracking when you right click a file, it basically does the same thing as hg forget or git rm --cache, removing the file from repo but not from hard disk.
add it to your ignore list.
See the .hgignore file.
TortoiseHG gives you access to this config file via the "Edit Ignore Filter" menu option.