I'm using TortoiseHg. I have a file A. I used the rename tool to rename this to B. All seems well. Now I want to create a new file named A. When I create a file with that name and go to add it to the repo, it's showing me a diff of my new file with the old A (which is now renamed to B.)
How can I rename A to B and be able to add a new A which is, y'know, new, and not have Hg think I'm modifying the old, now-nonexistent A?
Edit: In fact what I originally did was the right thing, I just wasn't committing the rename properly. (I had committed, but only committed the newly-renamed file, and not the now-nonexistent old file.)
You need to commit after the rename and then create the new file with same name.
$ hg mv A B
$ hg commit -m "moving A→B"
$ touch A
$ hg add A
$ hg commit -m "adding new A"
Suppose you the file a.txt in your repository. To rename it to b.txt and add a different file named a.txt, using TortoiseHg 2.x, do the following:
Right-click a.txt. In the context menu, click TortoiseHg > Rename File.
In the Rename dialog box, enter b.txt into the Destination text box. Click Rename.
Right-click the repository folder. In the context menu, click Hg Commit.
In the Commit window, make that you have two files checked, added b.txt and removed a.txt. Enter the commit description, and click Commit. Close the Commit window.
Create new file named a.txt. Right-click it. In the context menu, click TortoiseHg > Add Files.
In the Add window, make sure that a.txt is checked. Click Add.
Right-click the repository folder. In the context menu, click Hg Commit.
In the Commit window, make that you have a.txt checked. Enter the commit description, and click Commit. Close the Commit window.
Now you have a different a.txt, with a fresh history, and b.txt which remembers it used to be named a.txt.
P.S. This is exactly the same steps as Vaibhav Bajpai posted in his answer. You may have a hard time if you have problems dealing with steps expressed as hg commands.
Related
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.
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.
I receive a patches from a contributor. Apparently, he produces the patches in trunk. However, I would like to commit his changes to a new branch. May I know how I can do so through Tortoise-Hg?
The directions found below assume you want the patches isolated on a named branch.
Using the command-line, it is easy to apply patches to a new named branch. However if you want to do this using TortoiseHg only, you must create the named branch with an empty commit prior to applying the patches.
Using the command-line:
hg branch <branch name>
hg qimport --push <patch-file-1>
hg qimport --push <patch-file-2>
hg qfinish --applied
Using TortoiseHg v1.1.x:
Import the patch files to your patch queue (without applying them).
Create a new named branch using an empty commit:
Open a commit dialog
Click the button labeled "branch: default"
Select "Open a new named branch"
Enter your branch name in the provided text box
Click the OK button.
Enter a commit message (e.g. "Created branch for patches from ") and click "Commit".
Apply the patches in your patch queue (one at a time or all together).
Right-click on the patches in your patch queue and select "Finish Applied"
Using TortoiseHg v2.0.x:
The same process used for TortoiseHg v1.1.x will work. The process to create the named branch with an empty commit is slightly different, but the overall concept is the same.
In TortoiseHg 2.7, update to the branch you want to apply the patch to (or create it if it doesn't exist). Choose Repository > Import and use Browse... to select an individual patch file, or Browse Directory... to import a folder of patches.
The original branch from where the patch came from doesn't matter to hg import unless you use the option --exact. So, you should create the branch you want and apply the patch:
hg branch new_branch
hg import /tmp/patch.txt
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.
Short version of the question: Since I already have TortoiseHg, I right clicked on that file trying to see the merge conflict visually, but there is no way to see it?
Details:
To make a simple case of merge conflict, I hg init a repo on Win 7, and then clone it to another folder.
Now, in one working directory, i added the line "the code is 123", committed.
And in the other folder, i did an "hg pull" and "hg update"
Now, I go back to the first folder, and change "123" to "123abc", and then do an "hg commit"
And then I go to the other folder and edit "123" to "123xyz" over there, and do an "hg commit", and when "hg push", it says it can't.
So I try to use any visual tool to see how the conflict is like, but ... TortoiseHg doesn't seem to have any option to do that?
There isn't a conflict yet. Same as svn or cvs you need to fetch changes into the second repository before you can commit back to the first and it's this that creates the conflict. In the second repository, you need to
hg pull to fetch the 123abc change from your first repository; this'll be created in repoistory 2 as a new branch
hg merge to merge the changes - now there's a conflict that you need to resolve
hg commit to commit the resolution of the conflict
and now you can hg push.