Merging in my Mercurial repository is not working like I expected.
Several days ago I started work on a feature then realized I could not finish it before sprint end. I updated back to the point in time that I started work and continued from there (effectively creating a branch). Now I am ready to merge the changes from that branch back into the tip, yet for some reason when I merge nothing happens. TortoiseHg says the merge went fine, and both the tip and the changeset that I'm trying to merge from are bold in the Repository Explorer but none of the changes from the branch are in my working directory.
Here is a video of the unexpected behavior: http://screencast.com/t/ZTQ0ZjU1NTM
Notice that when I go to commit there are no changes detected. In what way is this a merge?
Am I missing something? Is Hg broken? I could've sworn that I've done this before and it went off without a hitch.
Can you try it from the command line?
hg update -r48
hg merge
hg commit -m "merged"
Related
I am working in branch A and am using eclipse mercurial plugin to manage version control.Mistakely while pulling and updating the changes from the remote repository I pulled and updated changes of all the branches of my project.Now my branch A has changes of other branches say B , C , D .. as well.
I go-ogled and found out that hg rollback is likely the solution however I am not sure.
How do i undo my last pull and update? Any suggestion would be appreciated.
For a direct hands on How to revert a Mercurial hg pull?. Also look the Mercurial FAQ (7.13).
The hg update is never a problem, just do hg update YOUR_LOVED_REVISION_NUMBER and your working directory is again with all your stuff, and only your stuff.
Assuming you and only you works in the A branch, the hg pull is either a problem, just other's work in other's branches in your backstaged Mercurial internal history. If you like your history (DAG) clean then you may hg strip those annoying branches in your local repository.
Assuming the A branch is co-worked, then the hg pull just imported the other's work to your local copy of the project.
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.
We have a code review repository where people hg push -f all sorts of stuff. After reviews are complete, we pull from the project's central repository, rebase, and push. I recently upgraded to mercurial 2.1 and get this message:
abort: can't rebase immutable changeset 43ab8134e7af
(see hg help phases for details)
when I try to hg pull --rebase from the central repository. How do I fix it?
In the review repository's .hg/hgrc file, add these lines:
[phases]
publish = False
The problem is due to a new feature in mercurial 2.1 called phases. It's great. Here is a nice introduction to its use.
To make the changesets in question mutable right now, use hg phase -f -d REV to force REV to be mutable again. Once the hgrc file has been changed, you shouldn't have to do that any more.
As a side note, hg push -f is lame. Make an alias hg review that pushes with -f to that repository.
I don't think disabling phase support on the server is the correct solution, but your problem sounds weird.
Pull --rebase should rebase your local changes, on top of the remote changes, which should be allowed, even if phases are supported by the client, as long as these changes have not been seen by anyone else, eg. they haven't been pushed out anywhere.
Is it possible that you have already pushed your your own changes, to somewhere else (which set them to public phase), and after that tried pulling from the testing repo? Because then, this is the correct behaviour that you are seeing.
Most of the time it is a bad idea to mess with phases manually (with hg phase -f), because it can easily lead to a history rewrite, which can lead to duplicated changesets, or various errors when other people try to pull/push. If a changeset became marked as public (as in your case), it probably happened for a good reason.
I've encountered such behaviour with collapsed rebase. Phasing out back to draft hadn't helped me. So I've just pulled up (hg pull -u) to sync with remote repo, then just grafted the problem commit (hg graft <problem_commit>) and then amended this very new commit.
I'm new with HG, I'm looking for some advice on how to handle this scenario.
We have a central repo hosted at Kiln. The three guys on my team code away and eventually are ready with our code which we tag and release as Version1. We then happily start working on our next major version. While working on it, there's the need to fix a critical bug in Version1 so James clones his repo using hg clone -r Version1 http://centralrepo where he makes his change and tags it as Version1.1.
Now, how does Version1.1 get back to the central repo? Using hg push causes an abort because there are two remote heads. Without it being in the central repo, Doug can never come along and make a fix to Version1.1 if it ever becomes necessary.
How can I modify my process so that all my tags are always stored on the central repo and easily pulled into the dev branch?
UPDATE/EDIT
With the suggestion from Joel, I made the following tweaks:
On the Kiln website, I create my main active dev repo. Once I have the code in there, I create a new branch from it.
I clone my ActiveDev branch: hg clone http://activeDev code-activeDev
I clone my Stable branch: ht clone http://stable code-stable
I setup a tag on my stable branch: hg tag V1.0 and then push it to the stable branch and to the active dev branch. When going to activeDev I use the -f command. Now both branches are identical.
I do an hg pull and start on a new feature in ActiveDev. Then push that feature back to central:
hg com
hg push
Stable gets a bug fix, then pushed to it's own repo using the same two commands. Now when I try to push that fix to the activeDev branch, I'm again given the 'you are making two heads, use -f' message. However, if I force it, the new feature I pushed earlier in activeDev is blown away by the fixes I did in stable.
Did I do something wrong? Am I missing a step somewhere?
Basically, you need to merge the fix so that there is only 1 head again. There is a way of managing 2 branches that makes doing bugfixes on released versions (in parallel with development) easier:
The process I use is to create a named branch called Stable in addition to the default branch. I work on new features and whatnot on the default branch. Whenever I do an actual release of code, I merge that over to the Stable branch and only tag things like v1.0, v1.1, etc. on that branch.
Then I can continue development on the default branch, but when a bug comes up that is relevant to a previous version I can put that fix on the Stable branch and recompile. When ready, I merge fixes from the Stable branch over to default to make sure that Stable is always just a subset of default.
If you start using this, the first time you push that named branch to central you will have to use hg push --force, but only once.
I've got a named branch (same repository) that was created in order to to spike something. I've now decided that I want to move all the changesets created in the branch back into the main (default) and then close the branch.
I've tried a number of different things, including what was outlined in this post (How to repeatedly merge branches in Mercurial) but I just can't get it working :(
Can anyone provide any pointers?
Thanks.
Merge the feature branch into default
hg up default
hg merge feature-branch-name
hg ci -m 'merged feature-branch-name into default'
Close the branch you don't want to use anymore
hg up feature-branch-name
hg ci --close-branch -m 'close feature-branch-name branch'
hg up default
Note that the close command doesn't have any disruptive effects on the repository history
It flags your branch as closed so that it won't appear in hg branches and hg heads commands output
I've managed to solve my problem using the link I mentioned in my question. The steps described in the link had actually merged my changes across however I didn't realise as I was looking in the TortoiseHg UI and couldn't see the changes there. When I performed hg outgoing via the command line it appears that the merge had worked correctly.