This question is the same as: TortoiseHg: Push Branch, except it is for TortoiseHg 2.0. The old way no longer works. The options are not even there.
Here is the issue: As I work on different bugs, I create different branches for each. How can I push just one branch using TortoiseHg 2.0?
When I go into sync view, and push - I believe it tries to push all my local branches, and ends up aborting - since multiple heads would be created.
The feature exists in TortoiseHg v2, but the interface changed. In the Sync tab, there is the following menu:
Enable the "Target" checkbox
Select the branch you want to push
Push as you normally would
Related
I just found out that we're not supposed to create named branches in our local Mercurial repos, because they get carried along and pushed to the upstream repo, where they live forever.
Unfortunately, I already have multiple feature branches in my local repo, which I was all set to merge to default and push up to the main repo. So, what I need to do is keep the work in these branches (somehow) but remove the named branches.
Is there a way to do this, short of a lot of horrible manual revert/cut/paste?
Using TortoiseHg:
(Ensure rebase extension is enabled in File -> Settings -> Extensions)
Update to parent of the first change set of the named branch.
Right click on the first change set of the nambed branch and click rebase.
Ensure "Keep orignal branch names (--keepbranches)" is NOT checked.
Ensure "Rebase entire source branch (-b/--base)" is checked.
Click rebase.
Another approach would be to use the hg convert command (a standard extension) and the branchmap option.
For a private repository or at least one with changesets which have not been published this would work fine, even though like a rebase it would modify history.
An advantage as opposed to using rebase is that it could be used to deal with multiple branches (named or unnamed) all at once. That might be quicker / easier if there was a lot of things to move around.
A secondary plus is that since convert will create a NEW repository there is no risk to the original if something doesn't work as expected. (Of course when using rebase you could make a backup first which I think is a reasonable precaution.)
I couldn't find a relevant thread anywhere, but possibly this important task has to be asked about many times before..
I have a central repository, from which I have cloned to form a local repo. Now I made several changes and commits to local repository. Now I need to push/commit the final version to central repo. How do I do this?
I'm using TortoiseHg as the client.
When I right click, in the context menu of tortoise, I can see Update as well as Synchronize. I am not sure if either of these are meant for my job. If I select Update I see an Update to combobox where it has default, tip etc. Not sure what are these. When I select Synchronize, all I see are (confusing) options that deal with remote repository. Or does remote repo mean central/main server repo?
Thanks.
You can have more than one (any) amount of remote repositories.
Mercurial is DVCS (D - Distributed). Central/Main is just conventional repository, which all teammates use for intermediate code-storage (by agreement and workflow)
Synchronize toolbar (most right in toolbars, when enabled) is your best friend
1 in screenshot is for actions-button for data-transfer (read hints for buttons /and THG help/)
2 is section of defined remotes (in your case, after clone, you'll have only "default" alias), for which selected (by button) action will be performed
PS: from CLI it's a lot faster:
cd REPO_DIR
hg push
Maybe this is a bit late but.....
if you are familar with subversion, think of (mercurial) update as a (subversion) switch...and (mercurial) synchronize as (subversion) checkout and/or commit.
I am trying to work out how to use the Branch-per-feature approach in mercurial but having created a branch to work in, and merged it back to default, am unable to push my changes back up to my master repository. What is best to do?
I created a branch "Gauge customisation", did some work in that branch and then merged it back into the default. Carried on with a few more changes in default and now I want to commit this back to my master repository. But when I try I get:
abort: push creates new remote branches: Gauge customisation!
hint: use 'hg push --new-branch' to create new remote branches
I didn't think the branching would show up in the master repo and that by merging it locally I could somehow work in the branch (or potentially branches) and then when I've tested everything, push it up to the master repo.
Should the Gauge customisation branch still show up? Really I thought I'd only see default at this stage? But is that me not understanding the tools properly? Should I be creating the remote branch?
Ideally I'd like to be able to open a branch per feature and have 3 or 4 such branches running at any one time (it's the way my company works) so I'd like to get a solid grasp of things now.
Technically you could just commit the new branch to the master repo using --new-branch. As displayed in your screenshot, there is not really a new branch with a head from a topological view, but from a namespace view, i.e. when hg aborts your push, it just wants your explicit acknowledgement to add a new branch (name) to the remote repo.
However, for tasks like your's -- temporary feature branches -- a more common workflow is to not use named branches but anonymous/bookmarked branches or separate clones. Named branches usually are used for long-living branches like stable, legacy, and so on. If you create an anonymous/bookmarked branch and merge it back when its feature is finished, hg won't complain when pushing.
An often recommended reading in that context is A Guide to Branching in Mercurial.
Merging two branches does not get rid of either of them. You will need to close your feature branch manually by switching to it and doing:
hg commit --close-branch -m 'Closing branch'
I am trying to grok Mercurial and hope I am just getting confused here!
I have a repository ('main') that I have cloned ('clone'), , both on my own machine. Both were completely in sync with each other.
I decided to play with named branches so the next time I committed on my 'clone' I did it under a branch name of 'case1212' and while it seems to have dealt with the commit properly on my clone, I cannot push these changes back to 'main'. The error given is:
abort: push creates new remote branch 'case1212'!
...and it suggests that I might need to merge first? What am I supposed to merge on that 'clone' repository? When I try to pull from 'main', there are no changes.
I'm pretty sure I actually would want it to create a remote branch in my 'main' repository so people who update from it can see that branch.
Mercurial's default behavior prevents you from creating remote branches. If you want to do this, you need to force-push.
Synchronize menu in the window you show, there is an option for force push.
Tortoise now has an option Push new branch that may be safer than Force pull or push. The command line tool has a flag --new-branch.
Update: The new tortoise interface makes it a bit harder to find. Switch to the Synchronise view, then click options and select allow push of a new branch.
It's warning you that your push would create new remote heads (and in this case branches). If you're okay with that, and it sounds like you are, you can push with push -f.
This check is in there so that if you wanted that case1212 branch to not go back to the main server you could do hg push -r default and then you'd not see this warning and not send case1212.
Once you've done this for case1212 you won't see the warning again since case1212 will already be there.
Newer versions of mercurial make that warning a little less scary sounding in the case where the new head is a new branch.
I downloaded TortoiseHg 1.0 for evaluation. For the life of me I can't figure out how to make a branch. It seems to understand branches (e.g. in its repository browser) but I just can't seem to find a way to make a branch. This seems like such a fundamental capability since out of the often touted benefits of DVC is the lightweight branching.
I Googled around and couldn't find much discussion of this topic (at least for recent versions) so I have to assume I'm missing something, right?
Update: So I flagged Chad Birch's answer below to answer the "new branch" issue. As he correctly points out, you do a commit and then click on the branch button to bring up the branch maintenance dialog which is where you create new branches. I kind of wish they had given us a context menu option for this. Once you've branched, the next natural question is how to merge and this is also not obvious. It turns out that option is buried in the repository explorer. You need to select the head of another branch, right-click and then select "Merge with...".
As shown in the docs, all you should need to do is just click on the branch: default button near the top of the commit dialog, and change to a new branch name.
To start new branch with TortoiseHg press Commit... then, above Commit message press Branch, then "Open new named branch: "
Just wanted to add that in order to push new branch to remote repository there is a checkbox on the Synchronize tab under Options of "Allow push of a new branch" - you have to remember to turn it off again right afterwards.
Most of the time in mercurial, you clone the repository to make a branch.
You can then merge the separate repositories once you made your edits and commits.
This might sound like it would take up a lot of disk space but on most operating systems, mercurial will make hardlinks instead of copying the files. Anyway, disk space is normally cheap, and because it's local it's rather fast.
If you think about it, every "checkout" (in svn terminology) or "clone" (in mercurial terminology) is really a branch that will probably be merged back so it makes lots of sense that clones are the common way of making branches.
Before commiting, click on Branch button (see image), Then select a branch or create a new one (by typing where you select the branches).
See the image here