In effect, I would like to do the opposite of "Merge with local"
To clarify:
We have a release branch and a default branch. When doing bug fixes on the release branch, here's the routine:
Update to the release branch
Implement bug fix, and commit
Update to the default branch
Right-click on the bug fix commit from the release branch, and select "Merge with local..."
Since a lot of work is done on the release branch, it gets tedious to Update between the branches all the time. In previous versions of TortoiseHg, I could select the branch before doing the merge, in effect doing a "Merge local with selected". This would eliminate steps 1 and 3 above.
Is this doable in TortoiseHg anymore?
Three-way merges are basically symmetric: you merge two divergent versions of your code (the two branches) into a single version (the merge commit). There is no technical different between updating to default and merging with release, or doing it the other way around. In particular, the merge conflicts are exactly the same.
In Mercurial, there is an extra twist because of the named branch names: by default, the merge commit will inherit the branch name of its first parent. If you don't update to default before merging, the first parent will thus be release. But you can change the branch name before committing.
On the command line it's just:
$ hg update release
$ hg merge default
$ hg branch default
$ hg commit -m 'Merged release into default'
In the pre-2.0 versions of TortoiseHg you were presented with this dialog to commit the merge:
The button above the commit message saying "branch: release" could be used to change branch of the next commit — the merge commit. In TortoiseHg 2.x the dialog looks like this:
and there's no longer a button for changing branch.
Maybe you can ask the TortoiseHg developers to add the button again, or you can use Henrik Stuart's TortoiseHg if you want a pre-2.0 TortoiseHg that is compatible with modern versions of Mercurial.
I haven't found a way, even command line merge is always with local. I just keep a clone for each branch and switch between clones instead of updating a single clone. For large projects this prevents the usually time-intensive "rebuild all" when changing branches. Adds extra pull step but saves time overall:
In release clone, implement bug fix and commit.
In default clone, pull from release and merge with local.
Related
I have 3 commits which I pushed to the public repository accidentally. I want to revert to an older version (a version before these 3 commits happened) and make it the current code in our public repository.
I am using TortoiseHg,version 2.11.1
Option 1
You can use the strip option as mentioned in the command
hg strip is the command
This extension has to be enabled
Enable the extension by adding the following lines to your .hgrc or Mercurial.ini:
[extensions]
strip =
This option is only suitable if you have access to the central repository where your code is hosted and you have a small group in which you would know if someone have already pulled your changes.
Option 2
Another option would be to backout these 3 commits, Since you are using UI,I will attach a screen shot
Step 1: Right click the unwanted commit and you will see a backout option click that and the wizard wll guide you.
if its a merge that you are trying to backout then you have to select which branch to backout to.
Do the same for the 3 unwanted commits
Option 3
if you have many commits and if its in a named branch following these steps will provide a solution
1) Close the branch and update to the last good commit you want.
2) Reopen the barch from there by new commit (Named branch can have multiple heads)
3) use hg revert -r and commit
This will make the working directory exactly as the last good commit you need and ignore the inwanted commits. This will only work if the commits are in a named branch.
You can do it like this:
hg backout -r <rev>
hg push
This will backout to the <rev> revision (which should be the last correct commit). In other words, it will set your working directory into the same state as it was on the last correct commit and create a new commit with an explanatory message. Then you'll push it to the public repository so it's the current code again.
I am trying to do something very simple: create a new branch. But I messed up. Where did I make the mistake, and how do I fix it?
I am the only user of Mercurial. I had revision 54 committed and pushed to remote repository. I wanted to create a branch based on revision 53, so I updated my local copy to revision 53, made changes, and committed (ignoring the warning about "it's not the head"). Then when I am trying to push to remote repository, it says
abort: push creates new remote head
Maybe I needed to tell Mercurial that I want to create a new branch? If so, how and at what point?
Thanks!
You tell Mercurial that it can go ahead with
$ hg push --force
You need to force it since multiple (unnamed) heads are normally discouraged. The problem with them is that people that clone the repository wont know which one to use. But since you're the only user you can just go ahead and push.
The alternative is to use a named branch (with hg branch) and then you'll use
$ hg push --new-branch
to allow the creation of a new branch on the remote. Named branches have the advantage that they make it easy to distinguish the two branches. They have the disadvantage that they are permanent. Permanent means that you cannot remove the branch name from the changesets on the branch — the name is literally baked directly into the changeset.
Bookmarks provide a way to have non-permanent branch names, see hg help bookmarks.
Another reason for this error: probably there are some UNMERGED changes form the central repo in your default branch.
hg up default
hg merge
hg ci -m "Merge"
hg pus
I did this. Using TortoiseHg ... this is how I fixed it:
In settings, I enabled the Strip extension then right clicked the branch i did not want, Modified History - strip. If you have pushed, then it needs to be stripped from all other repositories, including workmates who have pulled your unwanted branch.
An alternative is to merge the unwanted branch into your main branch, but do not take any of the changes from that branch - I am unsure of how that mechanism works.
When getting the latest code from a Mercurial repo on the command line, if there are changesets that need to be merged Mercurial raises a warning:
hg up
abort: crosses branches (merge branches or use --check to force update)
This is what I expect, and from the Mercurial book it says "Mercurial is telling us that the hg update command won't do a merge; it won't update the working directory when it thinks we might want to do a merge, unless we force it to do so." At this point I know I need to merge.
How can I get the same behaviour using TortoiseHg? When I hit "Update", it happily updates me to the most recent changeset. Is there a way to warn me that a merge is probably needed? The "Always merge (when possible)" option seems to only apply when you have uncommitted changes.
The reason you get an error from hg update on the command-line is that it doesn't know which revision to pick. There are 2 divergent default heads.
If you were to execute hg update -r <specific rev>, the command completes without error.
When using TortoiseHg, you update by:
right-clicking a specific changeset
selecting Update...
This translates to hg update -r <rev>, so there is no error.
Using TortoiseHg, you always have the revision graph in front of you. The graph shows when newly pulled changesets create a new head.
The Mercurial abort you are seeing is occurring because you have outstanding (ie: non-committed) changes in your working directory, are trying to perform an update, and Mercurial has decided that you should probably perform a merge instead.
TortoiseHg should also warn you about this, but it will do so in a different way. It will spawn a dialogue that asks if you want to Discard, Merge, or Shelve your outstanding changes. This is what it looks like in TortoiseHg v2.X.X, but it should be similar in v1.1.X:
If you're not seeing this in TortoiseHg, you may not have any outstanding changes. Try it again - are you seeing these options?
It seems naming a previously unnamed branch doesn't really work out. It creates a nasty multiple heads problem that I can't find a solution for.
Here is the workflow...
UserA starts working on feature that they expect to be small, so they just start working(off the default branch). The change turns out to be a large project and will need multiple contributors. So UserA issues... hg branch "Feature1" and continues working, committing locally s needed.
UserA then pulls down the changes from the central repo so he can push.
At this point, why does hg heads return 3 heads? It shows 2 for default and 1 for Feature1. The first head for default is the latest change by another user on the branch(irrelevant). The second default head is the commit prior to the hg branch "Feature1" commit.
The central repository has rules enforced so that only 1 head per branch is allowed, so forcing a push isn't an option. The repo doesn't want multiple heads on the default branch.
UserA should be able to push these changes so that other users can see the Feature1 branch and help out. I can't seem to find a way to "correct" this. I don't think I can re-write the branch of the initial commits for the feature, before it was a named branch.
I know the initial changes before the named branch are technically on the default branch, but does that mean they will be heads until that Feature1 branch is merged?
I have found a solution without have to re-clone and merge changes in. I prefer this method mainly for historical purposes as I think it's valuable information on what happened with the feature (aka it started small and then was re-thought to be larger etc..)
In my example, UserA should update to the unwanted head on default and close that branch of default, as it is unwanted. This will leave 2 heads one for default and one for Feature1 as expected.
hg update -r X // X is the rev of the unwanted head.
hg commit --close-branch -m "Moved to Named Branch Feature1, cleaning up initial work"
Then update to the Feature1 branch, push and continue working.
Another workflow is almost the same except the UserA decided to push Feature1 for others to help and default has not been moved forward by anyone else. The local repo only has 2 heads and the user could push, but UserA does NOT want to just push as the tip of default would now be the changeset that really "belongs" to Feature1.
UserA should update to the latest, unwanted changeset of default. Then revert the default back to the revision before UserA starting working.
hg update default
hg revert -r Y // Y is the changeset before UserA started working on the feature
hg commit -m "Reverting changes that now exist in Feature1 branch"
Then update to the Feature1 branch, push and continue working.
The reason you're seeing two heads on the default branch in the local repo is because, after the most recent common ancestor, the changesets in the central repo have nothing in common with the changesets in the local repo.
To solve your problem:
Create a new local clone of the central repo at whatever revision you want (it will probably be easier if you use the most recent common ancestor).
hg clone -r common_ancestor central local2
Export the changes from the first local repo. Note the colon after first_local_change to get all the changes in that repo.
cd local1
hg export -r first_local_change: > ../local1.patch
Go to the new local repository, create the feature branch to import the changes into, then import them:
cd ../local2
hg branch feature
hg import ../local1.patch
hg import has an option to use the branch information in the patch file, but it's disabled by default.
At this point, you can continue using the new local repo in the original one's place. Also, I would double check to make sure that everything is as it should be in the new repo.
We found this to be a very big problem with our team (doing branch-per-feature) and ultimately stopped the hgweb.cgi script working (HTTP 414 Request too Long).
from hg help heads: hg heads with no args will show branch heads, which by definition are changesets that have no children on the same branch. hg heads --topo should give you result you need in this case.
Don't go via the central repository. Just have your developers pull from each other.
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.