I run into the following issue all the time with Mercurial, and it's very annoying:
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
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
将中止更新。
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)"
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")
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.