Using Mercurial, do we need "hg merge -r 6880" if there is an additional branch?

Question

For Mercurial, right now there is a default branch and a newfeature branch ... is it true that if I am a newfeature branch and do hg pull and hg update , will it always ask me to merge? (if there are changes that I pulled)

Also, it seems like I can't just do hg merge ? I need to use hg heads , and then look at what the head of the newfeature branch newfeature (let's say this is version 6880 ), then I need hg merge -r 6880 ? Because otherwise, Mercurial will automatically merge the newfeature branch with the default branch? I can't do hg merge -b newfeature , it seems, since there is no -b option for hg merge .

Is there an easier way besides using hg heads to find changes to merge? Is there a more automatic way?

Answer 1

You have two questions, let me take them one at a time (with a little rephrasing):

Q. When I hg pull and get a new Mercurial chapter, suppose I am hg merge . Should I?

A. No. Mercurial simply warns you that you have more goals than you, and that if you do not like this agreement, you can merge to stop it. Named branches are heads, so you will see this warning if you pull a new head along with you.

Q. If I want to merge the same branch into another, should I provide a version number?

A. No. It’s true that hg merge will automatically select heads in only the same named branch, but you can make hg merge -r newfeature and this merge in the set of changes from the point of difference to head on newfeature (6880 in your example) is exactly the same as hg update -r 6880 .

In any case, after completing this merge, you will not have goals for newfeature (the new, resulting head is on default , because it was the name of your parent branch before you started the merge. Doing this after the merge:

 hg update newfeature ...code.... hg commit 

will create a new branch in the newfeature branch, and you will go back, as before the merge, except that all the changes that were in the new function are now available in default .

Answer 2

If you push a change set or change a set from one branch to another branch that uses the same root change set. Mercurial will have several heads, as you have noticed. This will only assume that you merged when you do hg update on one of the branches.

You do not need to specify which version to merge to, assuming that you want to combine the tips each branch. hg merge should be enough.

Your team structure should look like this

 hg pull -b 'branchYouWantToPullFrom` hg update hg merge hg commit 

Answer 3

hg merge works in your working copy, which is always associated with a specific branch.

You need to specify the branch name only if you want to merge the current branch with another branch: hg merge branch_name .

hg pull updates your repository with all changes removed. Then you need to update the working copy associated with the specific branch. Therefore, when you enter the hg update command, you update the working copy with all the changes in the current branch. If you want to switch to another branch, you must enter hg update branch_name . You can enter hg branch to find out your current branch.

The only reason to merge with a specific revision is when you have three or more goals, a strange situation, probably caused by some hg push -f (extremely bad practice). If you are in this situation, the right way to find out what changes you should combine is hg heads . In a normal situation, hg heads returns one heading per branch, so you don't need to combine two heads of different branches if you don't want to.

If you are working on a branch, and someone made it and pushed some changes in one branch, you need to pull it out and merge it before you click, just using hg merge , without changes or branches.

Hope this helps you.