Mercurial push problem_问答_开发者_运维开发者技术经验分享

I've just got a problem with hg push command. What I did - Firstly I created 2 branches hot-fix-1 and hot-fix-2 made some changes in each branche, merged it back to default and closed those branches with the command:

hg commit --close-branch

If I start hg branches I have the following output:

default      29:e62a2c57b17c

hg branches -c gives me:

default                       29:e62a2c57b17c
hot-fix-2 开发者_如何学运维                    27:42f7bf715392 (closed)
hot-fix-1                     26:dd98f50934b0 (closed)

Thus hot-fix-* branches seems to be closed. However if I try to push the changes I have the next error message:

pushing to /Users/user1/projects/mercurial/mytag
searching for changes
abort: push creates new remote branches: hot-fix-1, hot-fix-2!
(use 'hg push --new-branch' to create new remote branches)

and it does not matter which command I use hg push -b . or hg push -b default

So the question is how I can push those changes to repository without creating new branches.

P.S I used to work with git and was hoping that similar branching model can be used in Mercurial. Thanks

First, as many others have pointed out, using a named branch for short lived work is not a recommended practice. Named branches are predominantly for long lived features, or for release management.

Given that you are in this situation, there are a few options available. All of them involve modifying history (as you're obviously trying to change something you've done).

One is to just push the branches as is, learn from the experience, and move on. If the rest of the team is fine with this, then it's a case of adding --new-branch to your push command.

If the rest of the team, or you, really want the history to be clean, then you'll need to dig deeper.

If you aren't pushing, then definitely make a clone of your current repo. This way you have a copy of the original work to fall back on.

I see 2 main approaches here. Strip off the merges and rebase your branches onto default. This will get rid of the named branches or graft/transplant your changes. Both will be the same end result, but the implementation is slightly different.

If you merely want to use graft, that is now a built-in function starting with HG 2.0. It replaces the transplant plugin, and is much nicer to work with as it uses your usual merge tool if there are conflicts.

To use it, update to the default branch. Then, use the command:

hg graft -D "2085::2093 and not 2091"

the string after -D is an hg revision selection query. In your case, you'd likely only need '{start}::{end}' where start is the changeset at the start of the branch, and end is the end changeset of the branch (ignoring the merge).

If you did several merges, you'd have to pick and choose the changesets more precisely.

The other option is to strip the final merges, and use the rebase command that is part of the mq plugin.

You'll have to strip your merge changesets to get rid of them, and then update to the tip of the branch you want to keep. Select the start of the first named branch, and do a rebase. This will change the parentage of the branch (if you're familiar with Git, then this is very much like it's rebase).

Then repeat for the second branch. You should now have one long branch with the name default.

Just do the:

hg push --new-branch

It will send over those branches, but they'll be closed on the receiving end too, so no one should be bothered.

See my comment on the question for why Named Branches are best saved for long-lived entities like 'stable' and anonymous branches, bookmarks, or clones are more suitable for short lived things like hot-fixes and new features.

Your hot-fix changes were made on branches. Regardless of whether the branch is active or closed, it does exist.

To push the changes to the server (without rewriting history), you must use the --new-branch option (e.g. hg push --new-branch`).

Since you merged the branches into default, there will still only be one head (as you have already seen in your local repo).

If you really can't live with pushing the branches to the server, then you must rewrite your local history as suggested in Mikezx6r's answer.

In addition to the methods he mentioned, you can also import the changesets into a patch queue and apply them to the tip of your default.