I read some information about named branches and working with bookmarks. Unfortunately I still don't see a difference between them. Is there any?
Is there any difference between:
hg branch blah
hg up blah
and
hg bookmark blah
hg up blah
?
Why would I use a bookmark and how is it different from a named branch?
Bookmarks are tags that move forward automatically to subsequent changes, leaving no mark on the changesets that previously had that bookmark pointing toward them. Named branches, on the other hand, are indelible marks that are part of a changeset. Multiple heads can be on the same branch, but only one head at a time can be pointed to by the same bookmark. Named branches are pushed/pulled from repo to repo, and bookmarks don't travel.
There's a great branching comparison here: http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
Related
How can I duplicate a branch in Mercurial? I need the new branch to be against head (as the first one is).
The GIT equivalent (if I was in branch-a) would be:
git checkout -b branch-b
A Mercurial branch is a named entity that consists of all the commits contained within the branch. So in order to duplicate some existing branch, you must also duplicate all of its commits to new commits that are in the new branch. We then get into metaphysics arguments about commit identity. It's probably not a good idea to go here at all, but if you do want to go here, use hg graft to copy all the desired commits into the new branch.
A Git branch consists of a name containing a raw commit hash ID. So duplicating a Git branch under a new name is trivial. Note that the set of branches that contain any given commit changes dynamically over time: a branch that was only on feature/tall may now only be on master, even though that commit is still that commit, even via most of these metaphysical arguments. (Only the "no identity over time" argument lets us claim that this is not the same commit.)
Another way to put it is that Mercurial's branches actually mean something, but Git's don't. If you need true branches, you can't use Git in the first place. Don't try to import Git's bizzareness into Mercurial: you'll just make your own life miserable.
Meanwhile, though, Mercurial contains a DAG just like Git. If you use Mercurial bookmarks, those work like Git branches. It's probably wiser, then, to just use bookmarks and be done with it.
If all else fails, see hg graft.
the new branch to be against head
What is this (in usual business-term, not Git-lingua)? While in common (and in details) #torek is totally right, he forgot to write exact command-set, something like
hg up <rev-id>
hg branch <new-branch-name>
hg graft -r "branch(old-branch-name)" --log
Mercurial - What are the steps involved to accomplish the rename of a branch after it has been created and committed to (both locally and in the central repo).
For example, I've created a branch called Zelda and then committed and pushed to a central repository. I now want to change the name of the branch to Triforce.
Is there an extension that accomplishes this? What might be the long way in addition to any extension solution?
The short answer is no.
The long answer is, Mercurial branches are names attached to changesets. If you have several changesets committed to the branch zelda and given away (i.e., pushed to the central repo), there's no way you can rename that branch without re-creating these changesets, which means rewriting history.
Even if you strip those changesets both in you repo and in the central repo, then re-create them as belonging to the branch triforce, and push the “renamed” branch again, all of your collaborators will end up having two copies of the changesets, one set on branch zelda, another on branch triforce.
So yes, what you should do is described in https://stackoverflow.com/a/7245187/67988. To quote from there, adjusted to your branch names, i.e. zelda is the old branch to be closed and triforce is the new branch to be created.
hg update zelda
hg commit --close-branch -m "mgmt: Close branch zelda"
hg branch triforce
hg commit -m "mgmt: Create branch triforce"
hg push --new-branch
P.S. If no one else pulled from the central repo yet, you can try stripping zelda from there. Or, if you have access to all other devs' PCs (assuming a controlled environment), and really want to go one very dangerous road, you can strip this branch from all the repos. This is definitely not considered good practice, and can only be used as a last resort measure.
The mutable-branches extension can give the illusion of having renamed a branch.
I have been using named branches both as feature branches and long lived branches. I just merged a bunch of feature branches into a long-lived branch, so I no longer need those feature branches muddling up the history graph (although I still want to keep the commit messages of course).
How do I do this?
Checkout the branch (hg co branchname) then hg commit --close-branch to mark the branch "closed".
Branches in mercurial are permanent, which is why they're a good choice for things that live forever like "release 1.0" and "experimental". For features you might want to consider something more transitory like bookmarks, clones, or anonymous branches. All four options are very well described here: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
As #wolvever shows you can hide it from a list, but you can't get rid of it without making your repo a different repo entirely (and thus breaking all clones).
We converted everything to Mercurial coming from CVS and so far so good. An issue we encountered today though is this situation.
Before the move to Mercurial I had a few pending changes from a while back, features that were started and later postponed for various reason. Odds are that someone else will finish those features months from now picking up from where I left off.
After cloning the new Mercurial repository I created separate branches to isolate those features.
It left me with something like this (made up rev. number)
hg update default
hg branch feature1
hg commit -m "Description of what I was doing in feature1"
hg update default
hg branch feature2
hg commit -m "Description of what I was doing feature2" (my tip is now here)
hg update default
hg push -f (to force the creation of my new branches, w/o affecting default, I haven't merged them)
During this the team have been working and pushing to our central repository so the default branch is say rev 40 (tip)
Now my push -f worked fine but positioned (tip) to my latest change -> 50:feature3 (tip). I was expecting the tip to stay at default on the central repository and just have my branches in there for someone to pick them up whenever. The graph also looks pretty funny when I use hgwebdir so I am pretty sure that's the wrong approach.
How would I do this? Should I close the branch first? Is tip actually important or just meta-data.
tip is always the most recent changeset added to the repository. From hg help revs:
The reserved name "tip" is a special tag that always identifies the most recent revision.
So long as the head of the default branch is what you expect, you'll be OK. No need to close the branch (but it's better to use hg push --new-branch if your version of Mercurial is new enough to support it).
tip is just an automatically-applied label referring to (I think) the most recent commit. Not a big deal; it's just there for convenience.
The tip label is pure meta-data and always points to the changeset with the highest revision number -- there is no more logic than that.
However, the fact that tip now points to a changeset on the feature branch wont cause you any trouble. When people make a clone, they will automatically be updated to the tip-most changeset on the default branch. So they can begin working right away after a clone. Furthermore, people who already have a clone will stay on their named branch when they run hg update. Here hg update takes you to the tip-most changeset on that named branch, e.g., on default if that is where you started.
People may think that hg update tip is the same as hg update, but that is only when there are no named branches at play. With named branches, giving an explicit revision name such as tip can changeset your named branch -- a plain hg update cannot.
Is there a way to associate a bunch of Mercurial changesets with a named branch after they have been committed, i.e. retroactively ?
I just wanted to do this, and here’s the solution I found.
A year has passed since the question was originally asked, this might explain why I can now find a solution.
It has the disadvantage that you create an extra revision in the process, but this wasn’t too bad for me.
First, you go back to where you want to create the branch.
In my case, I actually wanted to start a new root (because I wasn’t very sensible when I started the repository, but anyways), so I’m updating to null. You probably want to start somewhere else, it depends on your situation.
$ hg update null
Then, create the branch.
$ hg branch blah
$ hg commit -m "Created blah branch."
Then, we rebase all the commits we made onto our new branch:
$ hg rebase -s SOURCE -d DEST
The SOURCE here should be the first commit you made in the commits you want to create the branch from, and the DEST should be the commit where the branch was created (the one we committed above).
No, branch names are part of the changeset (it's really like a label you add to the commit), it means the changeset hash depens on the branch name.
So the only way to change it retroactively is by rewriting history (which doesn't play well if you pushed your changes elsewhere, since you'll have to rewrite every repo which has the changes).
To rewrite history, you could use for example mq.
Not a complete solution but, without re-writing history; you could tag the last change set in the unnamed branch. If you never rebranch from this the tag should surfice. If you do need to rebranch you can move on to a named branch after the tagged changeset.