I have done a 'hg merge' however when I attempt to do a 'hg commit -m "my msg.." I get the following error message :
abort: cannot commit merge with missing files
Can anyone explain how to fix this to allow the commit go through?
Try hg status and look for files in state ! (missing).
The cause is that one of the files which is part of the merge has been deleted. Undelete the file and try again.
Heres my approach
hg status will tell you what files are missing. Then you can either restore the file from somewhere
OR type in hg remove <path/name of missing file>
THEN commit. Your repo will be sane again, darwin willing.
If you are using TortoiseHG, click in View/Commit. It will show you files in state ! (missing).
Right click on the file and choose Revert (undelete the file) and commit.
Related
When trying a
hg commit
or
hg status
I'm getting the error
abort: invalid subrepository revision specifier in .hgsubstate line 3
This is probably why:
f322ee070c467d1e517564d679f150693739d186 buildtools
2e68a7e2306704c8dc98802c73897c6c43bf96bc dzlivetemplates
libs/dxgettext
libs/dzlib
libs/jcl
libs/jvcl
libs/tregexpr
The first two lines look OK, but starting from the 3rd line there is no GUID for the subrepository revision.
I have no idea how this happened (but I probably caused it myself).
How do I recover from this? Can I just delete the .hgsubstate file and have hg recrate it from the current state of the subrepositories? If yes, how?
OK, deleting the file (actually I renamed it to be able to restore it) seems to solve the issue.
hg update
hg commit
restored it.
Now I'm back with the original problem: Getting rid of the unintentionally created second head. But that's a different story.
I'm using mercurial Hg in command line. After created a patch, I needed to revert to another changeset due to some errors happened later. Now it's needed to refresh the patch file. When executing Hg qref it says, abort: working directory revision is not qtip. Also, hg parent is a tip.
I'll add an answer to help other people that may encounter the same error message in the future. I'm not sure our issues was identical but definitely related.
I got "abort: working directory revision is not qtip" while trying to apply a patch onto my working directory.
It turned out that I had older patches in the patch queue which caused the problem and after I deleted these and tried again it worked!
Here's what I did:
Opened a console window and navigated to the working directory where I entered the command:
hg qseries
this listed the patch queue. Then to delete the old patches I entered:
hg qdelete [patch name (which was just listed)]
The response in my case was "abort: cannot delete applied patch ..." and to resolve this I entered:
hg qpop
This unapplied the patch and then I could use the "hg qdelete" command again which now work. Repeated this until all old patches were gone and tried to apply the new patch again.
Found the solution in the "Mercurial: The Definitive Guide", written by Bryan O'Sullivan, under section 12.7.1. http://tortoisehg.bitbucket.io/hgbook/1.4/managing-change-with-mercurial-queues.html#id2858507
Hope someone finds this useful!
It happened due to popping the current head out of the queue. In order to refresh, the patch should have been taken into the head of the queue by qpush.
Sometimes I can't seem to be able to track the merge conflicts.
I need a command that allows me to discard one of my uncommitted files and then update it with the remote copy.
I tried hg revert myfile followed by hg pull , hg commit
but it still won't let me merge or commit.
It keeps telling me to fix unresolved conflict first.
You might need to let Mercurial know that you have resolved the conflict, using hg resolve. From the man page:
hg resolve [OPTION]... [FILE]...
redo merges or set/view the merge status of files
Merges with unresolved conflicts are often the result of non-interactive
merging using the "internal:merge" configuration setting, or a command-
line merge tool like "diff3". The resolve command is used to manage the
files involved in a merge, after "hg merge" has been run, and before "hg
commit" is run (i.e. the working directory must have two parents). See "hg
help merge-tools" for information on configuring merge tools.
The resolve command can be used in the following ways:
- "hg resolve [--tool TOOL] FILE...": attempt to re-merge the specified
files, discarding any previous merge attempts. Re-merging is not
performed for files already marked as resolved. Use "--all/-a" to select
all unresolved files. "--tool" can be used to specify the merge tool
used for the given files. It overrides the HGMERGE environment variable
and your configuration files. Previous file contents are saved with a
".orig" suffix.
- "hg resolve -m [FILE]": mark a file as having been resolved (e.g. after
having manually fixed-up the files). The default is to mark all
unresolved files.
- "hg resolve -u [FILE]...": mark a file as unresolved. The default is to
mark all resolved files.
- "hg resolve -l": list files which had or still have conflicts. In the
printed list, "U" = unresolved and "R" = resolved.
Note that Mercurial will not let you commit files with unresolved merge
conflicts. You must use "hg resolve -m ..." before you can commit after a
conflicting merge.
Here's how you pick up the version of the file from the server.
When you "hg pull", all changes from the server come into your copy of the repository. You can get the contents of a file in any revision using:
hg cat -r <rev> <file>
Use that to overwrite the local file, and commit.
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.