Is there an easy way of getting all the heads of current branch?
Currently I get the current branch name with hg branch and after that perform hg heads branchname.
So is there any shortcut to current branch name to prevent of using 2 commands?
PS: in bash we can do
hg heads `hg branch`
but is there native and cross-platform mercurial solution using revision set language.
Yes, use
$ hg heads .
The hg heads command takes an optional revision identifier. If you run hg heads X, you will get the heads of the branch of X — note the extra indirection. This means that you can use . (which means the working copy parent revision) to get heads on the current branch.
TBT!
hg heads -r "min(branch(.)) and branch(.)"(min() because "If STARTREV is specified, only those heads that are descendants of STARTREV will be displayed.")
hg log -r "head() and branch(.)"
Related
I just merged branch A into B, and for some reason the merge did not go well. I want to revert B back to where it was before the merge and try again like it never happened before. I was thinking of just doing
hg clone myrepo newrepo -r A -r 12345
where 12345 is the revision number before B's bad merge commit
I think this works, but I have a lot of other branches (most of which are closed using commit --close-branch) and this puts those branches back to an inactive state.
Is there a way to clone everything except revision 123456 or something? (where 123456 is the bad commit on B)
Assuming you have not pushed the merge changeset to any public location, the easiest solution is to use the hg strip command that comes with the Mercurial Queues (i.e. mq) extension.
From the wiki:
hg strip rev removes the rev revision
and all its descendants from a
repository. To remove an unwanted
branch, you would specify the first
revision specific to that branch. By
default, hg strip will place a backup
in the .hg/strip-backup/ directory. If
strip turned out to be a bad idea, you
can restore with hg unbundle
.hg/strip-backup/filename.
It might not be as nice as hg rollback, but usually what I do is update to head A, merge in previous head B, check that I got it right this time, and then dummy-merge away the bad merge.
I hope I'm understanding your situation correctly. If I am you should be able to update to the revision of B before the merge, give that revision a new branch name, merge A in to it, and continue on. You'll probably want to mark the original B branch as closed.
$ hg up 12345 #12345 is the revision of B prior to the merge
$ hg branch B-take2
$ hg merge A
$ hg commit -m 'merge A in to B-take2'
$ hg up B
$ hg commit --close-branch -m 'mark original B branch as closed'
Is it too late to use the hg rollback command? If so, try the hg backout command.
I have a Mercurial repo at Bitbucket and on my local machine, both are mirrors, up to date. I created a feature branch, reflected in both repos. I did all my work in the feature branch.
The feature branch is now complete and I want to now make it the default for the main repo and my local copy. I don't really care about the default branch, enough work has gone into the feature branch that all I want to do is designate it as the new default.
I don't think I want to merge nor should I? How can I do this so both local and remote don't get confused?
Just merge feature-branch into default then close feature-branch:
$ hg checkout default
$ hg merge feature-branch
$ hg commit
$ hg checkout feature-branch
$ hg commit --close-branch
There is no more clean and sensible way (that I'm aware of) to “make feature-branch the default”.
One thing that wouldn't be as nice, but you could do, is to make a commit to default on top of feature-branch:
$ hg checkout feature-branch
$ hg branch default
$ hg commit
But this would leave two heads in the default branch, which is suboptimal.
Since Mercurial 2.4, you can create an bookmark called # and Mercurial will checkout that revision new clones.
However, I would still try to stick with using default as the branch where the main development takes place. Doing so will cause the least amount of surprise for developers already used to Mercurial — the wiki describes the standard way to use branches in Mercurial.
If you follow the conventional advice of using default as the main branch for development, then you should close your feature branch before you merge it back:
$ hg update feature-branch
$ hg commit --close-branch -m "Feature done, merging into default branch"
$ hg update default
$ hg merge feature-branch
$ hg commit
If you haven't done any work at all on the default branch since your started the feature branch, then this merge will be trivial and have no conflicts. Otherwise you'll have to resolve conflicts. If you're sure you want to keep everything from the feature branch, then you can do
$ hg merge --noninteractive --tool internal:local feature-branch
$ hg revert --all --rev feature-branch
instead of just hg merge above. That will make sure that the new commit on default look exactly like the last commit on feature-branch.
I succeded without merging by closing the default branch.
in my development repository working directory:
$ hg update default
$ hg commit --close
then my development branch became the new default branch.
But i do not know the rules for why my development branch was choosen
as the new default.
i think it is because it was my tip ?
(or maybe last changed branch? (tip?))
I also think that you have to repeat that next time.
Because i think my chosen branch name was "overwritten" by the 'default' name.
It would be nice to have branch name.
dev-projectname-version.x=default
regards
I wanted to do just what you described and hunted around until I found an answer which uses the revert command to do just what you describe. Here is the code I used:
hg revert --all --rev ${1}
hg commit -m "Restoring branch ${1} as default"
where ${1} is the number of the revision or the name of the branch. These two lines are actually part of a bash script, but they work fine on their own if you want to do it manually.
This is useful if you need to add a hot fix to a release branch, but need to build from default (until we get our CI tools right and able to build from branches and later do away with release branches as well).
For Mercurial, right now there is default branch and newfeature branch... is it true that if I am on
the newfeature branch, and do an hg pull and hg update, it will always ask me to merge? (if there are changesets that I pulled)
Also, it seems that I cannot just do hg merge? I need to use hg heads and then look at what the newfeature branch's head is (say it is revision 6880),
then I need to hg merge -r 6880? Because otherwise, will Mercurial merge the newfeature branch with the default branch automatically? I cannot do hg merge -b newfeature, it seems, as there is no -b option for hg merge.
Is there an easier way other than using hg heads to look for the revision to merge? Isn't there a more automatic way?
You've got two questions there, let me take them one at a time (with a little paraphrasing):
Q. When I hg pull and get a new head Mercurial suggest I hg merge. Do I have to?
A. No. Mercurial is just warning you you have more heads than than you did, and that if you don't like that arrangement you can merge to stop it. Named branches are heads, so you'll see that warning if pulling gets you a new head
Q. If I want to merge one named branch into another do I have to provide the revision number?
A. No. It's true that hg merge will only automatically select heads on the same named branch, but you can do hg merge -r newfeature and that merges in the changeset from the point of divergence up to the head on newfeature (6880 in your example) exactly the same as hg update -r 6880 would.
In either case, after committing that merge you'll have no heads on newfeature (the new, resulting head is on default because that was the branch name of your parent before you started the merge. However, just doing this after the merge:
hg update newfeature
...code....
hg commit
will create a new head on the newfeature branch, and you're right back as you were before the merge, except all of the changes that were on new feature are also available in default now.
If you pull a changeset or changesets from one branch into another branch that share the same root changeset. Mercurial will have multiple heads as you have so noticed. It will only suggest that you merge when you do an hg update on one of the branches.
You shouldn't have to specify which revision to merge to, assuming that you want to merge the tips of each of the branches. hg merge should suffice.
Your command structure should look as follow
hg pull -b 'branchYouWantToPullFrom`
hg update
hg merge
hg commit
hg merge works in your working copy, which is always connected to a specific branch.
You have to specify a branch name only if you want to merge your current branch with another branch: hg merge branch_name.
hg pull updates your repository with all remote changes. Then you have to update your working copy, that is connected to a specific branch. So, when you type hg update command, you update your working copy with all changes in your current branch.
If you want to switch to another branch you have to type hg update branch_name. You can type hg branch to know your current branch.
The only reason to merge with a specific revision is when you have three or more heads, a strange situation probably caused by some hg push -f (extremely bad practice). If you are in this situation, the right way to know which revisions you have to merge is hg heads. In a normal situation hg heads returns one head per branch, so you don't have to merge two heads of different branches if you don't want.
If you're working on a branch and someone has committed and pushed some changes on the same branch, you have to pull and merge before your push, simply with hg merge, no revision or branch.
I hope this will help you.
If there are two branches, and I have been doing work on the default branch, I think one way to push to the foo branch of the other clone is
cd ~/development/clone2
hg up default
hg pull ~/developmet/clone1
hg up foo
hg merge default
or
cd ~/development/clone1
hg up default
hg push ~/developmet/clone2
cd ~/development/clone2
hg up foo
hg merge default
These 2 methods work exactly the same? (one is a pull, one is a push).
Is there an easier way to directly push clone1's default branch to clone2's foo branch? thanks.
(I use clone 1 to see all the changes I have done (without seeing anybody else's changes), and use clone2 to merge and integrate with other team members)
You can always push and pull a single revision and all of it ancestors using:
hg push -r revision ~/development/clone1
or
hg pull -r revision ~/development/clone2
There's no way to "push to another branch" because you'll always have to merge the two different branches manually
Both methods you described work exactly the same, but the first one is recommended (Always do the merge work in your clone, not the integration repository or somebody else's clone)
Maybe is an intentional omission but in both examples you have to commit the result of the merge and in the first example you have to push the merge changeset back to clone2
So in ~/development/clone1 do:
hg up default
hg pull -u ~/development/clone2
hg up foo
hg merge default
hg ci -m 'merged default into foo'
hg push ~/development/clone2
If you do this a lot you may consider adding this lines to your ~/development/clone1/.hg/hgrc file
[paths]
default = ~/development/clone2
This way you can omit the repository path when you're pulling and pushing from the integration repository
Is it possible to ask Mercurial to show only the heads of one branch? For example, I often want to double-check that default only has one head, but currently I need to do that "manually" (ie, checking the output of hg heads for more than one entry which is in default).
hg heads <branch name> works on Mercurial 1.5.3.
To get the heads of the current branch you can use:
hg heads .
And to get the number of heads of the current branch (in Bash):
hg heads -q . | wc -l