When using Mercurial, often I'll do hg push and I'll get this error message:
(use 'hg push --new-branch' to create new remote branches)
Which is fine, I understand why I get the message. But I always want to push any new branches so I was wondering if there was any way to force Mercurial to remember to always push new branches without me having to do:
hg push
...
(use 'hg push --new-branch' to create new remote branches)
---
hg push --new-branch
There was a way of setting default options for commands on mercurial using the [default] section on .hgrc, but it is now deprecated.
The recommended way of doing that is using aliases. On your .hgrc, put:
[alias]
pushb = push --new-branch
After that use hg pushb to push creating new branches.
You can add an alias in your .bashrc:
Example:
alias hgp="hg push --new-branch"
Then hgp will always successfully push the code.
Related
I'm using TortoiseHg with an SVN repository using the hgsubversion extension.
I like to use hg pull --rebase when I pull, to mirror what SVN does on svn update. Because I'm using hgsubversion, I will need to rebase anyway before I push, so I may as well do it in one step.
Additionally, hg push will automatically do a rebase internally, there is no way around that.
My difficulty is that hg rebase will refuse to work if I have any uncommitted changes. So to push or pull from SVN I always need to hg shelve first and then remember to do hg unshelve after. This can get really annoying and I always forget.
Ideally I'd like to tell TortoiseHg to do this for me automatically, but I'd settle for a command-line alias. I tried putting an alias like svnpull = !hg shelve && hg pull --rebase && hg unshelve in my config as suggested here but I get an error "user: abort: response expected" instead of being asked for my password. What can I do to avoid manually shelve/unshelve steps every time I interact with the central repository?
I can't actually commit my changes locally and just avoid pushing the local change, because hgsubversion doesn't respect the secret phase and hgsubversion doesn't support designating a revision to push. So unfortunately none of the answers to this similar question will work for me. And anyway I'd need manual steps to arrange for my "local only" changeset to always be on the tip.
The solution was to use repository hooks. I added this to my .hg/hgrc config file:
[hooks]
pre-pull = hg shelve
post-pull = hg unshelve
pre-push = hg shelve
post-push = hg unshelve
Don't enter password manually, automate it with keyring (questionable on Windows) or using [auth] section of in project's .hgrc
Sample from my local hg-repo for remote SVN-backend
[auth]
assembla.prefix = https://subversion.assembla.com
assembla.username = USER
assembla.password = PASSWORD
and entering password not needed anymore
Another idea: you haven't push immediatelly your WIP, yes? You have only to have it on top of "other" work, true? You can in this case commit, rebase, and continue to work with the same tip, modifying it with commit --amend
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.
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!
Is there any option to restrict a user to use hg push -f? Because it will remove intermediate commits by other users.
First of all, doing hg push -f cannot remove intermediate commits. Mercurial is built around an append-only history model and you cannot delete stuff from a server by pushing to it.
When a user does hg push -f, then he tells Mercurial to go ahead with the push even though it creates new remote heads. To prevent this, you need a hook on the server that forbids more than a single head. There are listed several such hooks here.
With Mercurial 1.6, it is no longer necessary to use -f when you push a new named branch. You should instead use hg push --new-branch. This is safer since it only allows the creation of new branches, not the creation of multiple remote heads.