I want to have local branch in my cloned repository that will not exist in main repository. To do this I create branch named "new_branch", develop and commit to it. Sometimes I make commites to default branch and after that I make "push -b default" that the branch "new_branch" not appeared in main repository. After the development in "new_branch" finished I make merge to default branch and I want to make push for default branch "push -b default". I get message "abort: push creates new remote branches: new_branch! (use 'hg push --new-branch' to create new remote branches)". Can I have a only local branch in Mercurial?
You can try:
LocalBranch Extension (only Tim Lee fork seems to work with current Mercurial)
MQ (and push without --mq option)
Phases can be used for this in modern Mercurial:
# hg phase --secret -r 7::10
Will mark changes 7 through 10 as secret, as so they won't be pushed, pulled, cloned, etc.
Once you create a branch using hg branch, it is a permanent part of the changeset. It will always require you to push using the --new-branch option. You cannot strip the branch name without modifying history.
If you want give a local name to a branch that does not get propagated when you push, then you should use hg bookmark instead.
Related
I cloned an hg repo and created a feature branch (via hg branch myfeature). I have staged & committed changes to it via hg add . and then subsequently hg commit -m "My new feature branch.".
I would now like to push those changes (in the branch; not as default) to the remote server (where I cloned the project from) so that other devs can code review the changes in the myfeature branch.
I found a blog that recommends using:
hg push --create-branch-remote
But this isn't working for me - any ideas where I'm going awry?
You forgot to read hg help push for your version of Mercurial
...
--new-branch allow pushing a new branch
...
Looks like --new-branch is what I wanted.
In my local repo, I have a file A and I made some changes. But I didn't want to submit this changes to remote repo. The question is if I didn't submit this changes in TortoiseHG, everytime I changed other files, A will be listed in the "changelist window".
I know, TortoiseHG has a shelve function. It can store temp files. But files in shelve will revert to origin status.
Commit the change and then modify the phase of the commit to "secret". Note that any child changesets of a secret changeset will also be secret.
hg help phases
You might want to maintain a private branch with these changes - just make the first commit to the branch secret and then periodically merge from the main branch to your private branch.
An alternative is to do the above but without making the changesets secret. This will allow pushing the branch to a central server which gets the benefits of backups, etc and also the possibility that these changes might be useful to other developers (but still not on the main branch).
Consider using Mercurial patch queues to manage local changes. With MQ you can queue up local changes and stash them out of the way for future use.
For the extension's documentation, here's the standard workflow you'd use for putting away local changes for future use:
$ hg qnew choosename
$ hg qpop
$ # ...
$ # restore
$ hg qpush
$ hg strip -k choosename
$ hg qremove choosename
There's also shelve, but I've never used it.
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.
Isn't this a normal workflow?
[default] $ hg branch foo
[foo] $ [... some commits ...]
[foo] $ hg update default
[default] $ hg merge foo
[default] $ hg commit -m "merged foo"
[default] $ hg push
abort: push creates new remote branches: foo!
(use 'hg push --new-branch' to create new remote branches)
What is the otherwise ideal way to do branching → merging → pushing?
The mercurial philosophy is that you should not be pushing things which make it harder for other users of the repository. Relevant to this question is that multiple heads make it harder for other developers, since they would then need to merge your changes. Hence by default pushing new heads is rejected by the server. The -f option was used to allow pushing new heads.
However, the case of pushing a new named branch is quite different conceptually to pushing a new head on the same branch. Many workflows (including mine) do each task on a separate named branch. The --new-branch option allows you to push up a new branch, whilst rejecting new heads on existing branches. It's also different (as you've seen) because it's needed even if the new branch does not create a new head (due to merging).
My personal feeling is that new branches should be allowed by default, but the mercurial developers prefer otherwise.
This is a one-time thing. Just use --new-branch the first time you push a (new) branch. It's normal.
Every other push can remain as hg push, no --new-branch flag.
That depends on what the branch is used for.
Is it used internally in your own repository clone it would be appropriate to commit your changes to your branch as long as you develop on your feature decoupled from the others.
After you finished you'll have to invest some work to keep track on the efforts of other people who may have done changes on the default branch
Then you should update in their changes, resolve the conflicts commit your part.
Switch over to default and make your feature part of the default branch by merging in your changes. Now you can close your branch, commit the stuff and push it!
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.