Accidentally used > instead of >> !
The overwritten file was added by hg add two days ago but was never commited.
Can hg undo that for me (maybe by magic) ?
No.
If you're using Eclipse, you can look into the "local history".
If you use Mac, Timemachine might have saved the file.
If you're using openSUSE with btrfs, the zypper snapshot mechanism might have kept a copy.
Related
I've been assigned the task to do a huge merge, ~1500 commits, on a mercurial project.
In the local fork we have deleted about ~200 files, right now I need to press d and enter for each file:
remote changed file/that/is/deleted/in/local which local deleted
use (c)hanged version or leave (d)eleted?
Is there a way to tell mercurial to choose to delete all those files?
Are you on a Unix-like system? If so, this command will automate answering "d" to all questions. That's what it's for. (Will only work if there are no other issues requesting manual intervention, of course.)
yes d | hg merge ...
If you're not, you could implement it yourself :-) E.g.,
perl -e "for (;1;) { print \"d\n\"; }" | hg merge ...
Or write a Windows batch file with an infinite loop (etc.)
YES.BAT | hg merge ...
since you are on windows, try using tortoise
https://tortoisehg.bitbucket.io/
add your project. then your working directory, you will be able to see the files affected, you can then
You deleted them on local? You can't just do an hg addremove? If they changed after removal, but before pushing I think you are out of luck :(
As per the second answer and its comments in Resolving conflicts: how to accept "their" changes automatically?,
hg merge --tool internal:local
will work.
I just lost a bunch of work because I accidentally clicked "discard" when I tried to merge in remote changes.
Can anyone recommend a way to recover my uncommitted local changes? :'(
Does Mercurial or TortoiseHg store a backup somewhere of the last deleted changes?
Was it through this window?
In which case, I'm afraid, no, there is not.
I believe this window calls the command hg update -r MY_BRANCH -C, where the -C flag denotes there will be no backups.
As an aside, if it was a different way, you'd want to be looking for .orig files, which would be the format of the backup.
Say I type hg add in Mercurial, and there a bunch of untracked files in my working directory that are not ignored. What is the easiest way to un-add all those files without explicitly typing the name of each file?
Can I just un-add them all with one command?
Preface
You must always ask questions, which contain as much information as possible. Because now your question, depending from some conditions, may have totally different answers.
Case One - no local modifications in already versioned files, only added (and not committed) files
hg revert will return your working directory to the state after the last commit, undoing all changes it it.
Case One - local edits, which you want to save and occasionally added files
Read about filesets in Mercurial.
Use fileset in the hg forget command, something like hg forget "set:added()".
Use hg revert or hg forget on the files (both do the same for a file you ran hg add on). To avoid typing out the filenames, you can use a fileset like this:
$ hg revert "set:added()"
This will revert the file back to how it looked in the working copy parent revision, i.e., it will become unknown again.
hg revert -r .^ path-to-file will revert the commit from the commit-set.
then commit and submit (if using jelly fish) and you'll see the files removed from the changeset. I don't know why .^ works yet, but somebody will probably know.
You could always just re-clone your repository and then replace (delete existing and then copy new) the .hg directory in your working folder with the one from the fresh clone... (assuming you have no pending commits..)
I don't want this file to be removed from other developer's machines, but I don't want it tracked anymore either. It is basically a setting file, that shouldn't have been checked in in the first place.
I think I have to tell the other developers to back up this file. Then I can do a remove, and add it to the .hgignore. Then they have to put the file back into their working directory.
It seems like hg forget would only work for my machine, and then next time another developer does a pull it would wipe out their file.
Any tips?
They don't need to back it up. It's backed up in the repository. You might want to get them to commit their latest version before they pull from you so they don't lose their latest changes. When they lose their file they can just do hg log <file> and then hg revert <latest revision - 1> <file> to get it back.
It seems like hg forget would only work for my machine, and then next time another developer does a pull it would wipe out their file.
Yes, non-versioned file will be saved (some time) only in your WC
If you don't want kill file and just ignore, you can
use -X filename on commit by hand (or write in aliases section)
install (on all workplaces) Exclude Extension (semi-automated solution from p.1)
TortoiseHg allows you to email a patch file of your changes to someone, but does it support applying patches?
If so, how do you apply a patch using TortoiseHg?
From Repository Explorer, Repository > Import...
It looks like there is no built-in support in TortoiseHg for this. Try this from a command prompt:
hg import my-patch-file.patch
That should apply the patch to your Mercurial repo and working copy.
First Stab Answer
You should be able to right-click on the patch file and choose "Apply patch..." - that's how it works for other TortoiseX clients. Make sure that you save the patch file to the same directory path it was generated from.
Downloading TortoiseHg 0.8.1 to test...
What may be also noteworthy is, that "Repository Explorer, Synchronize > Import..." (which internally does a "hg import") will automatically do a "commit" - this may not be always wanted behaviour.
Other possibility is to use unix "patch" command (on Windows perhaps use cygwin version) or use "hg import" directly with "--no-commit" option. Both will just make changes in working directory and you may review the changes and commit them later manually.
In 1.0, from Workbench:
Repository > Import...