I've spent the last few hours doing an enormous merge in mercurial. After 131 files merged, my merge tool, meld, crashed showing a python traceback. Trying to quit meld, I've inadvertently also quit out of the mercurial merge.
I'd quite like to just continue the merge from where I left off, e.g. something like hg merge --continue but I can't find an option to do that.
If I re-run hg merge it warns about uncommitted outstanding changes. hg resolve doesn't list anything to resolve, but I am most likely only about 60% of the way through the merge.
Is there a command to continue the merge from where I was?
In TortoiseHg:
Select all files which are still marked as conflicted
Right-click on the files, and select "Restart merge"
Resolve the files
Commit the change
From command line:
hg resolve --all (continue the merge with all files that are still marked as conflicted)
Resolve the files
hg commit (commit the change)
hg resolve does nothing. To list files which have outstanding conflicts, use hg resolve --list. (The prefix U means that the file is unresolved, R is resolved.)
Related
I run into the following issue all the time with Mercurial, and it's very annoying:
I'm at some revision A.
I have local changes, which I meant to commit or amend on top of A, but haven't yet.
I want to go to some revision B, but I forgot that I had local changes!
I do hg update B. Mercurial "helpfully" tries to rebase my local changes to apply on top of B. This typically results in conflicts, and it now asks me to fix the conflicts.
However, I don't want to fix the conflicts! I don't want my local changes to apply on top of B at all. I want them to stay at A, either as a new commit just after A, or amended into A, as the case may be.
Is there a way I can recover from this state? The only way I know how is to
fix the merge conflicts at B
go back to A, getting merge conflicts again
fix the merge conflicts again at A
commit my changes at A and go back to B
This is a lot of work, and it's pointless. I shouldn't have to rebase my local changes to apply on top of B, only to rebase them again to apply on top of A.
If there's no better way to recover from this mistake, is there a way to get hg to refuse to do an update when you have local changes? I never want to do that - if I wanted that I'd just commit the local changes and rebase them on top of B.
Getting the dirty files back after updating somewhere and back is a bit tricky. The "trick" is to make sure that your working copy has the dirty files after the first update.
So after you do
hg update $SOMEWHERE
and discover the mess because Mercurial begins opening merge tools, calmly close the merge tools and then run
hg resolve --unmark --all
hg resolve --all --tool internal:local
All files that were merged because you had changes in them will now look like they did in your dirty working copy. This includes files that were merged cleanly and files you were prompted to merge. Updating back is now possible:
hg update $BACK
hg resolve --unmark --all
hg resolve --all --tool internal:local
You should now be back to where you started. If you modified the files after the first update, then it is the modified version you see after the second resolve. This is why you will want to resolve the files after the first update.
hg update -c will abort the update if you have any uncommitted changes.
If there's no better way to recover from this mistake, is there a way
to get hg to refuse to do an update when you have local changes?
Add this to your ~/.hgrc:
[commands]
update.check = noconflict
This will still allow hg update with uncommitted changes as long as there is not conflict. You can also call hg help config.update.check for other possible options:
"commands.update.check"
Determines what level of checking 'hg update' will perform before
moving to a destination revision. Valid values are "abort", "none",
"linear", and "noconflict". "abort" always fails if the working
directory has uncommitted changes. "none" performs no checking, and
may result in a merge with uncommitted changes. "linear" allows any
update as long as it follows a straight line in the revision history,
and may trigger a merge with uncommitted changes. "noconflict" will
allow any update which would not trigger a merge with uncommitted
changes, if any are present. (default: "linear")
Maybe the answer is to avoid updating if the working directory is dirty.
Modifying the ~/.hgrc in the following way should help:
[hooks]
preupdate = test -z "$(hg status)"
We have two users working on the same class files in two separate git branches.
User A does nothing else but an "autoformat" Ctrl-Sift-F in Eclipse
User B just adds a space in a comment
Now we get a "conflicting change" and can't merge anymore.
Basically we are stuck just because of the autoformat.
How to resolve this situation in Eclipse git or on command line git bash?
You can use git merge -s ours or git merge -s their to decide which version of the file you wanna keep after the merge.
Resolve the conflict as you would with any merge conflict. It sounds like a pretty simple conflict to resolve. Or since the changes were trivial, the person doing the merge (i.e. the person who hasn't pushed their commit) can just reset back to a common commit, allowing them to pull the other person's changes.
git reset --hard THECOMMITID^
Where THECOMMITID is the unwanted formatting change. If it's just the most recent commit then you can use HEAD^.
I deleted a few files on my local filesystem which I am not using anymore and are just junk. Unfortunately they are tracked by version control (Mercurial). Now I see a large red '!' saying it is out of sync because of the missing files. How can I tell Mercurial that it's OK to remove those files without reverting all of them and selecting delete on them individually?
Either tell it to forget those files:
hg forget XYZ
hg commit ...
Or use the addremove command, or addremove option for commit:
hg addremove
Hg commit ...
Or
hg commit --addremove ...
Use the help to find more info on these commands:
hg help forget
hg help commit
I goofed up a merge. I'd like to revert then try again.
Is there a way to revert a merge before it is committed?
hg revert doesn't do what I'd like, it only reverts the text of the files. Mercurial aborts my second attempt at merging and complains original merge is still uncommitted.
Is there a way to undo a merge after an hg merge command but before it's committed?
hg update -C <one of the two merge changesets>
After you do hg merge, but before hg commit, your working copy has two parents: the first parent is the changeset you had updated to before the merge and the second parent is the changeset you are merging with. Mercurial will not let you do hg merge again as long as your working copy has two parents.
You have two options on how to proceed:
If you want to abort the merge and get back to where you started, then do
hg update -C .
This will update the working copy to match the first parent: the . always denotes the first parent of the working copy.
If you want to re-merge some files then do
hg resolve fileA fileB
This will re-launch the merge tools just as when you did hg merge. The resolve command is good if you find out at hg merge-time that your merge tools are configured badly: fix the configuration and run hg resolve --all. You can run hg resolve as many times as you want until you are satisfied with the merge.
Today there is hg merge --abort. See hg help merge.
Let's say you do hg status and you have three files modified. I know how to check in all three files (hg commit). But how can you check in (and then hg push) just one of the modified files?
Please check the output of hg help commit which reveals that you can do
hg commit foo.c
if you just want to commit a single file. This is just like Subversion and many other systems — no hocus-pocus :-)
Just do:
hg ci -I path/to/file -m "commited only one file"
That commits only one file, and you can push it, and none of the uncommitted changes will be affected.
On the off chance you're running on Windows, TortoiseHG (a graphical Mercurial interface) lets you select which files to commit every time.