this is kind of an boring question because I know how to almost do it, but the point is that I would like to see is there a better way than remove old file, add new file... I know TortoiseHg autodetects it, but that file has a separate history when I use TortoiseHg to anonnate it...
So is there a way to tell the mercurial this is a renamed file?
Please note I mix a bit here TortoiseHg and Mercurial, I know that one is DVCS, the other one is GUI for it.
It looks as though you are looking for hg rename:
The command
hg rename old new
will rename a file from old to new and register the rename. If you have already renamed the file, then
hg rename --after old new
will tell mercurial that the file has been renamed and that it should track it under the new name.
Related
I started with the file OldController.php and converted it to NewController.php. Here's my workflow:
Commit: Delete OldController.php and create NewController.php
Amend: Do some work on NewController.php
Amend: Do more work on NewController.php
(Pretty sure the amends hold no relevance, but figured I'd mention them anyways.)
So, how do I take the history of OldController.php and point it to NewController.php?
I know I can just go back and do this manually, but I'd like to know how to do this within mercurial.
Update back to the last revision where OldController.php still existed. At that point, use hg mv to effectively rename it to NewController.php. Commit that rename. This creates a new head.
At that point you have a few options:
Merge the commit you just made with the other head which already had NewController.php
Rebase everything starting with the first commit to include NewController.php onto the new head you just created.
Either way would be effective, but it depends on whether you want to preserve the history of this change, or you're OK just to make it look like you had renamed it from the get-go.
Use hg cp (or hg mv if you only want to rename the file) instead of deleting one file and newly creating the other. That way mercurial knows that the new file is based on the old one and will display history accordingly
We have moves and renames of files in our published mercurial history that were not properly recorded, so that they appear in the history as unrelated deletions and adds.
Is there any way to tell the repository about the connections so that --follow commands can work again?
(For non-pushed changes, here is a question discussing how to get mercurial to properly record moves/renames before you commit, as well as a useful tip here.)
One solution that works but is a bit brutal: You can login remotely on your central Mercurial server, fix the renames there as a local change and then ask everyone to clone the repo again.
This works since all Mercurial repos are equal. You just think of one as "central" but in fact it's a repo like any other. So if you have access to that, you can rewrite history there. The drawback is of course that every developer will notice, so they'll have to export any non-pushed changes they made, clone the repo again and then import the patch.
[EDIT] A possible workaround would be to create a new branch just before you did the bad rename, rename the files properly and then cherry pick all the changes after that into the new branch.
I'm not sure if it's a good idea to merge this branch into your original branch. If you did, then Mercurial would see two kinds of file renames in the past and I'm not sure which one it would follow.
So before you merge, I suggest that you create a small test/demo repo where you reproduce the situation and then try it out.
You can start a new head from before the rename, do the rename properly, then merge it into the head from the upstream server. It will give you a conflict. When this happens, revert the offending files to the revision from your new head (with the good renames; hg revert -r <rev> <files...>).
I'm working in this file and I come across a piece of code which I think has changed at some point in history, and I would like to know where it changed.
It's a pretty big file with a lot of history, so when I use hg diff, I get a enormous list and I don't think it's efficient to search through that.
It would be really neat if I can look into an old revision of the file, to see what the file looked like at a certain point in time. Then I can see how the code worked back then so I can conclude how the bug evolved. Of course, I want to do this without updating the file, because I'm currently working in it and have made changes in it.
So, is there any way you can look into the history of a file without updating it?
There are a few tools to help you:
To get the history of a file you can just use hg log FILE which is probably the best starting point.
You can also use hg annotate FILE which lists every line in the file and says which revision changed it to be like it currently is. It can also take a revision using the --rev REV command tail to look at older versions of the file.
To just list the contents of a file at a given revision you can use hg cat FILE --rev REV.
If it proves too hard to track down the bug using those tools, you can just clone your repository somewhere else and use hg bisect to track it down.
hg bisect lets you find the changeset that intoduced a problem. To start the search run the hg bisect --reset command. It is well document in Mercurial: The Definitive Guide.
I accidentally renamed a file outside of Mercurial. When I committed the change, Mercurial treated the change as two unrelated files (ie. a remove and a add). I need to go back to diff the two revisions but I don't know how to do so when Mercurial sees them as two respective files across different revisions. What can I do to diff the files?
You didn't say what operating system you were using. The following will work with bash on Linux:
diff <(hg cat -r rev1 file1) <(hg cat -r rev2 file2)
You can replace diff with another program like vimdiff if you want a visual diff.
If you want to actually fix the history so that Mercurial is aware of the rename (and can use that information in future merges if needed), there's a way to do so documented on the Tips and Tricks page on the Mercurial wiki.
Current contents copied here for ease of use (and in case the link gets broken later):
Steps:
Update your working directory to before you did the rename
Do an actual "hg rename" which will create a new head
Merge that new head into the revision where you did the "manual" rename (not the head revision!)
Then finally merge the head revision into this merge result.
Advice:
Make a clone first and work on that, just in case!
After finishing the steps, use a file compare tool to check that the original and the clone are identical
Check the file history of any moved file to make sure it is now restored
That being said, if all you want to do is compare the contents at the point in time, you can definitely accomplish that without making Mercurial aware of the rename (as mentioned in Stephen Rasku's answer). In fact, you can use a combination of "hg cat" and an external comparison tool to compare any files, not just ones that Mercurial knows about.
Fix history:
Update to first changeset with new-filename, save file outside WC
Update to parent of bad replacement changeset, replace file correctly (with rename tracking), commit, got second head
Rebase all changesets from old anonymous branch on top of fresh good changeset
--close-branch on bad-replacement changeset or delete this unwanted changeset or leave inactive head intact
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Mercurial: How to ignore changes to a tracked file
I have a file in a Mercurial repository that I want to have stand as an example configuration file, but while I'm developing it I want to make specific changes to it I don't want tracked, like a database password. I tried adding that file to .hgignore, but Mercurial still notices modifications.
Can I have a file "tracked" in a Mercurial repository, yet ignore future local changes to that file without removing it from the repository itself?
I don't think this capability exists (love to see someone else's answer with an option though :) ). The alternative I've used is to check a file into source control named "config.template" (as an example). The app actually uses a file named "config", which I then create by copying the template file. Then make sure that the "config" file is excluded in the .hgignore file so you don't accidentally check in sometime.
No, there is no support built into Mercurial to automatically handle this, well... not in the way you're asking about.
There's two states of a file:
Tracked
Untracked
The only thing the .hgignore file does is to help with all the commands that just looks at all the untracked files and add them to the repository (ie. add them for tracking.) Once a file is being tracked, it will always be tracked.
The rest is left to manual handling, which means that if you track a file, but don't want to commit changes to it, you will have to uncheck, ignore, or otherwise make sure the commit command doesn't commit it, every time you commit.
The preferred way to handle this is instead to commit a template. Then, if possible, you add a step to your build process that checks if the actual configuration file is present, and if not, make a copy from the template. This actual configuration file you ensure is not tracked, and added to the .hgignore file.
This way, you can change the actual configuration file, but unless you specifically add it to the repository, it will not be tracked automatically, and there's nothing to do during commit.
You can just exclude the file in future commits.
This can be a bother if you use hg from the command line as you would have to specify manually which files you want to commit but if you use something like tortoisehg you can just uncheck the config file in the commit form and it's changes won't go in to the changeset.