8

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?

Helgi
  • 5,428
  • 1
  • 31
  • 48
daviesdoesit
  • 805
  • 9
  • 14
  • 3
    Maybe this thread's answer fits: http://stackoverflow.com/questions/4378684/mercurial-can-i-rename-a-branch – wkl May 08 '12 at 17:39

2 Answers2

10

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.

Community
  • 1
  • 1
Helgi
  • 5,428
  • 1
  • 31
  • 48
  • 1
    Good answer. But I would close `zelda` before opening `triforce` and so keep the history linear. I think that looks cleaner. – Martin Geisler May 09 '12 at 08:01
  • @MartinGeisler: I recall running into some problems with branches closed the way you suggest. As far as I remember, in hgweb, branches which were closed, but with the closing changeset having descendants, were displayed as inactive, not closed. I don't know, maybe this was a bug which has been fixed since, but I usually leave the closing changeset alone, just to be on the safe side. – Helgi May 09 '12 at 09:59
  • 1
    In modern versions of Mercurial, a *closed* branch is shown with a faint color in hgweb. An *inactive* branch is not styled differently, at least not by the default style called "paper". Closing before merging also means that you get fewer topological heads in your history. Some protocol requests send the hashes of all topological heads, so limiting the number of heads can help with performance. It used to be the case that many heads could make our HTTP requests exceed the maximum length allowed by common webservers, but we now send the data in HTTP headers instead. – Martin Geisler May 15 '12 at 11:07
  • @MartinGeisler: I've double-checked, and I see you're correct. Either I had misinterpreted the original behavior, or it was fixed. Thanks for the heads up! I've modified my answer, and I guess I'll stick to your recommendation. – Helgi May 15 '12 at 12:14
  • 1
    Great! I know many, many people think it's unintuitive to close before merge. They say "but I'm not done with the branch before it's merged!" I think of it like this "the branch is *ready* for merging, so I'm done with it." The merge changeset is on the other branch and so merging comes *after* you finish work on the branch, i.e., after you close it. You can always reopen the branch: just make a new commit and it will be open. So it's OK to close it and submit for merge, reopen to address comments from the integrator, close again, etc. – Martin Geisler May 15 '12 at 14:02
1

The mutable-branches extension can give the illusion of having renamed a branch.

gidyn
  • 21
  • 4