I'm running hg 1.7.5 and I had a similar problem earlier on the mercurial mailing list and we could solve it by running hg revert -a. Now I did run hg revert and it didn't solve the problem. I had problems with my filesystems and I had to interrupt a transaction now when I ran `hg commit' I get a new head
$ hg commit -m 'changes'
skapade ett nytt huvud
ubuntu#ubuntu:/media/Lexar/montao/montaoproject$
The localized message means hg created a new head. hg diff shows nothing. Could you say what I can do?
$ hg heads
ändring: 322:d74d7e14fe44
märke: tip
förälder: -1:000000000000
användare: niklasro
datum: Fri Dec 02 02:22:31 2011 +0000
kortfattat: changes
ändring: 321:470a570041e0
användare: niklasro
datum: Sat Nov 26 22:38:16 2011 +0000
kortfattat: bug fixes for insert
ubuntu#ubuntu:/media/Lexar/montao/montaoproject$
Update
I had to do a merge which it could do, then I could commit and push so now there is only one head like it should be:
$ hg heads
ändring: 324:eccc83b75b58
märke: tip
förälder: 323:5842204042f5
förälder: 322:d74d7e14fe44
användare: niklasro
datum: Fri Dec 02 09:01:35 2011 +0000
kortfattat: changes
ubuntu#ubuntu:/media/Lexar/montao/montaoproject$
If you want to keep your recent changes, try this:
Copy the whole working folder to some other place
run hg update -r 321 --clean
Copy the working folder backup back (do not copy .hg folder from the backup)
run hg commit -m 'changes'
If you don't need your changes, you may just update to the rev 321 and then strip rev 322 using patch queue. I'm not used to work with hg in console, so I'll write how to do this in TortoiseHg.
First, enable the 'mq' extension:
Open 'HG Workbench'
Go to 'File->Settings'
Select 'Extensions' from the list of features
Check 'mq'
Save changes
Close 'HG Workbench'
Strip revision:
Open 'HG Workbench'
Select rev 322
right-click on it
select 'Modify history'->'Strip'
click 'Strip'
Related
Let's say I have a changeset I've tagged as "stable". Now I update to "stable" and then start writing my new feature, committing along the way. It's not ready yet, so I don't want to merge it back into stable at this point, but I need to go fix an urgent bug on another branch.
I update to the branch, fix the bug, and commit my changes. Now I want to get back to where I left off, how do I do that?
I can "tag" my feature branch so that I can find it again, but AFAIK tags don't float along my branch as I commit, so it will always be a few revisions behind. This is good for "stable" because I don't want that tag to move, but bad for my feature branch.
How do I deal with this?
It just occurred to me that I can hg up <tag> and then run hg up a second time, and that will bring me to the tip of the branch, no? Seems a bit awkward to run hg up twice in a row, but if that's the Mercurial way of doing things, so be it.
In Mercurial a bookmark is a tag that moves forward whenever you commit. It sounds like precisely what you want:
(df)ry4an-mba:~ ry4an$ hg init smooth_reggae
(df)ry4an-mba:~ ry4an$ cd smooth_reggae/
(df)ry4an-mba:smooth_reggae ry4an$ echo this > AFILE
(df)ry4an-mba:smooth_reggae ry4an$ hg commit -Am first
adding AFILE
(df)ry4an-mba:smooth_reggae ry4an$ hg bookmark stable
(df)ry4an-mba:smooth_reggae ry4an$ hg checkout stable
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
(df)ry4an-mba:smooth_reggae ry4an$ hg summary
parent: 0:fdb32de55e6b tip
first
branch: default
bookmarks: *stable
commit: (clean)
update: (current)
(df)ry4an-mba:smooth_reggae ry4an$ echo more >> AFILE
(df)ry4an-mba:smooth_reggae ry4an$ hg commit -Am second
(df)ry4an-mba:smooth_reggae ry4an$ hg summary
parent: 1:38cdabce7149 tip
second
branch: default
bookmarks: *stable
commit: (clean)
update: (current)
(df)ry4an-mba:smooth_reggae ry4an$ hg log -g
changeset: 1:38cdabce7149
bookmark: stable
tag: tip
user: Ry4an Brase <ry4an-hg#ry4an.org>
date: Wed May 08 20:02:05 2013 -0400
summary: second
changeset: 0:fdb32de55e6b
user: Ry4an Brase <ry4an-hg#ry4an.org>
date: Wed May 08 20:01:31 2013 -0400
summary: first
Are you using an unnamed branch as your feature branch? If not, your branch surely has a name that you can use in hg up <branch_name> to get to its tip.
I did a series of dumb steps with my local copy of our shared repository, and I'm looking for a way how to fix it. The steps are:
I used bookmarks to have multiple heads of a development branch, that other people use:
-o---o---o-----o--- <- dev branch
\----1----1------ <- another head of the dev branch,
where I committed stuff
I created a new branch, still local, some time later
/---------------x <- new branch
-o---o---o-----o--- <- dev branch
\----1----1------ <- another head of the dev branch,
where I committed stuff
for one head, that contains only my code, I did a rebase on another branch
/-1'--1'-- <- rebase
/---------------x <- new branch
-o---o---o-----o--- <- dev branch
\----1----1------ <- another head of the dev branch,
where I committed stuff
then, I merged the rebase, and then, a couple of commits later, I merged default
----------d-\ <-default
\
/-1'--1'\ \
/---------------x--------x--x-x-x-- <- new branch
-o---o---o-----o---
\----1----1------
Now, I wanted to push my new branch to the server (hg push --new-branch -b newBranch), but I get abort: push creates new remote head, since commits 1' belong to dev branch.
What is the right thing to do? I would like to avoid creating this additional head.
Update:
Per request, this is the output of hg heads:
changeset: 839:f2033d695fcd <- want to push this
branch: newBranch
tag: tip
user: me
date: Wed Oct 31 13:05:51 2012 +0100
changeset: 826:7fde19d7f467
branch: devBranch
user: my-collegue
date: Tue Oct 23 14:59:42 2012 +0200
changeset: 820:23853bbf68df <- the part after rebase that got merged
branch: devBranch
user: me
date: Mon Oct 22 15:36:26 2012 +0200
changeset: 807:899344cfb145 <- obsolete (branch with 1's)
branch: devBranch
parent: 711:454f29c03fb1
user: me
date: Mon Oct 22 15:36:26 2012 +0200
changeset: 712:d5e8a62a7f5f <- default, needs to stay
parent: 648:2bbcc01aa191
user: me
date: Wed Aug 22 16:21:09 2012 +0200
You can push only the one head you're interested in mercurial. For you that would mean doing:
hg push -r f2033d695fcd
If the destination repo has been updated you need to pull, merge, and re-push:
hg pull
hg up -r <remote head>
hg merge -r f2033d695fcd
hg ci
hg push
I solved the problem, without pushing another head to the repo, and without merging 23853bbf68df onto newBranch. This is probably not the cleanest way to do it, but I will leave it as a reference. In a nutshell, I reconstructed the whole branch by taking all commits and re-applying them.
First, I killed the newBranch'es head 899344cfb145, by using strip on the first diverging revision I did:
hg strip -r 646
Then, I produced email patches (couldn't play with mq) for all commits that are in newBranch, since it's inception:
hg export -g -r 797:808 -r 810 -r 815:822 -r 824:830 -o "%n-%m.patch"
797:808 are the patches in newBranch that were in the rebased part of devBranch (1' commits from the original figure).
810 and 815:822 are other patchs in newBranch. 811:814 belong to a different branch, so I had to exclude those.
823 is a merge commit with default, so I skipped this one.
824:830 are all the commits after the merge with default.
Now, I imported these patches on a new head of newBranch:
hg up -r 796
# there are 29 patches, applying till merge
hg import --bypass {01..21}*.patch
hg up tip
hg merge default
hg ci -m 'merging in default'
hg import --bypass {22..28}*.patch
Finally, I just stripped of the original head of newBranch.
hg strip -r 797
This may not work in every situation. During the merge, I had to resolve some conflicts, too, but pretty benign. Hope this helps someone.
Here's what I did. I don't want two heads. How do I fix this?
~/src: hg push
pushing to ssh://hg#bitbucket.org/Neil/project
ruprojecting ssh hg#bitbucket.org 'hg -R Neil/project serve --stdio'
searching for changes
new remote heads on branch 'default'
new remote head e04226a528b5
abort: push creates new remote head e04226a528b5!
(did you forget to merge? use push -f to force)
~/src: hg push -f
pushing to ssh://hg#bitbucket.org/Neil/project
ruprojecting ssh hg#bitbucket.org 'hg -R Neil/project serve --stdio'
searching for changes
14 changesets found
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 14 changesets with 30 changes to 67 files (+1 heads)
remote: bb/acl: Neil is allowed. accepted payload.
~/src: hg pull
ruprojecting ssh hg#bitbucket.org 'hg -R Neil/project serve --stdio'
pulling from ssh://hg#bitbucket.org/Neil/project
searching for changes
no changes found
~/src: hg heads
changeset: 1177:e04226a528b5
tag: tip
parent: 1175:b5f77a454e64
user: Neil
date: Sat Feb 25 09:12:48 2012 -0800
files: src/experiments/distribution_combination.py
changeset: 1176:f7cc8d94f4f3
parent: 1162:b680e6f93f80
user: Neil
date: Thu Feb 23 15:32:36 2012 -0800
files: .hgignore src/CMakeLists.txt etc.
If you don't want additional heads - don't do it
Instead of dumb push -f:
hg incoming && hg pull
hg merge
hg commit
hg push
hg merge
That will prompt you to merge the two heads back into one. Rather, it will merge everything it can automatically, and prompt you about conflicts. Afterwards you can diff the result and submit it as a new changelist.
This is usually an indication that someone else has pushed since you last pulled. While you can provide the -f flag to force the push, as you have seen this just results in a new head.
The solution is to update to the head that you want to merge into, and run hg merge, then commit/push.
Commited work. Did a rollback when I wasn't on the tip of the repo. Lost files. Looking for git reflog equivalent to save my work.
Long:
So I finish work, then commit.
$ hg commit -A
[...]
adding media/js/fbfriends.js
removing media/js/streams.js
adding media/js/templetizer.js
[...]
$ hg log
$ hg log
changeset: 10:ce3ad416d9a5
tag: tip
user: Mihai
date: Sat Sep 10 22:34:35 2011 -0700
summary: Save all.
changeset: 9:ceacb7b2192a
user: Mihai
date: Sat Sep 10 22:25:34 2011 -0700
summary: Mootools update.
[...]
Some browsing:
$ hg checkout 8
Okay. Then I wanted to change revision 10. Stupidly, I do:
$ hg rollback
rolling back to revision 9 (undo commit)
$ hg status
[...]
M media/js/mootools.js
R media/js/streams.js
! media/js/fbfriends.js
! media/js/templetizer.js
[...]
WTF? Where did my two files go????
$ hg log
changeset: 9:ceacb7b2192a
tag: tip
user: Mihai
date: Sat Sep 10 22:25:34 2011 -0700
summary: Mootools update.
[...]
Okay, i'll figure out the .orig files:
$ hg revert --all
[...]
undeleting media/js/streams.js
forgetting media/js/templetizer.js
reverting media/js/mootools.js
[...] // media/js/fbfriends.js doesn't even show up
$ hg status
? media/js/mootools.js.orig
$ hg history
changeset: 9:ceacb7b2192a
tag: tip
user: Mihai
date: Sat Sep 10 22:25:34 2011 -0700
summary: Mootools update.
NOOOOOO! I've been royally fscked for being on commit 8 when i did the rollback.
Recovery attempts fail:
$ hg checkout 10
8 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ find -name temp
$ hg checkout 9
30 files updated, 0 files merged, 63 files removed, 0 files unresolved
$ find -name temp
$ hg checkout ce3ad416d9a5
abort: unknown revision 'ce3ad416d9a5'!
$ hg checkout ceacb7b2192a
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ find -name temp
$
But, but.. I pushed it in! It should still be somewhere in .hg? Help?
git reflog, git checkout blah saved me in a couple instances but are there any mercurial equivalents?
EDIT: Made summary clear.
EDIT2: Better title.
Sorry, they are gone.
The help summary for the rollback command is:
roll back the last transaction (dangerous)
and goes on to say:
This command should be used with care. There is only one level of
rollback, and there is no way to undo a rollback. It will also restore the
dirstate at the time of the last transaction, losing any dirstate changes
since that time. This command does not alter the working directory.
Rollback is the only non-extension mercurial command that removes history, and there's been talk about moving it to a disabled-by-default extension like it's similarly destructive cousins strip and purge.
Not that it helps you now, but in the future clone before doing a rollback. Or better yet do a backout instead. Backout adds the inverse of a change, yielding the same resulting tip revision, but with a more accurate history ("I did this", "I undid it").
C:\Users\Itu\workspace\Compiler>hg branches
default 13:aa6af82c5458
C:\Users\Itu\workspace\Compiler>hg heads
changeset: 13:aa6af82c5458
tag: tip
user: Itun
date: Sun Sep 18 22:27:06 2011 +0400
summary: Update 1.0.0.2
changeset: 9:d36e5ac454b1
parent: -1:000000000000
user: Itu
date: Sun Sep 18 06:50:25 2011 +0400
summary: New PR
changeset: 8:758cd394d82a
user: Itun
date: Sun Sep 18 06:48:17 2011 +0400
summary: asdasd
changeset: 4:c4c981b4ff43
user: Itun
date: Sun Sep 18 03:31:58 2011 +0400
summary: Update
C:\Users\Itu\workspace\Compiler>hg merge
abort: branch 'default' has 4 heads - please merge with an explicit rev
(run 'hg heads .' to see heads)
How you can see I have the one branch and 4 heads.
When I try to pull in my eclipse mercurial plugin, it returns me message about multiple heads and offers me to rebase or merge. Then I did not understand anything and closed it.
I think I need something to delete this heads. It would be great if somebody could explain me this and show how to do this in the eclipse plugin, but other help is appreciated.
The safest way to remove the extra heads is to make a new clone, grabbing just the head you want with -r:
cd C:\Users\Itu\workspace
mv Compiler Compiler-backup
hg clone -r aa6af82c5458 Compiler-backup Compiler
This will move just aa6af82c5458 and its ancestors to the new clone, leaving the old heads in Compiler-backup. You can always hg pull them over later, or just delete the backup (losing your data).
Mercurial has an entire wiki page devoted to the topic of multiple heads.
I highly suggest reading it before proceeding on your apparent course of action.
The folks at Fog Creek have provided some friendlier material.
You might consider working with them, since it sounds like you might need some support.