6

I'm working on a project which is using mercurial and it's gotten into a bit of a mess with a number of heads which for all intensive purposes are dead.

I want to kill off these heads and bring the commit graph back to a single line.

I've been told there's a way to merge branches but at the same time ignore any file changes, so essentially just merging the tree, but I can't seem to work out the command set.

Is there a way to do this, kill off branches by doing merges and ignoring the file changes? Or alternatively is there a way to bring in the graph again without the changes (which are not massively irrelevant in the project)?

Aaron Powell
  • 24,927
  • 18
  • 98
  • 150

2 Answers2

5

If you are using TortoiseHg and named branches, you can select the branch option in the commit dialog to close a branch and it will allow you to commit without having an actual file change.

It will still leave you with a head, but it will be marked inactive.

Binary Phile
  • 2,538
  • 16
  • 16
  • 2
    That's how I do. The command line for that is `hg commit --close-branch` – barjak Dec 17 '10 at 10:08
  • While it does leave the head still there (and, if you really want, you could commit to that head later to re-open the branch), it will ignore it as a head for most operations (eg `hg heads` and, more importantly, `hg merge`). `hg push` will still require you to use --force, however. – Matt Dec 17 '10 at 20:34
  • This works ... for named branches. But most of my work is with the anonymous n-headed hydra. –  Dec 02 '11 at 07:34
  • 2
    This will work for anonymous branches (heads without a branch name) as well (as of Hg 2.0.2). Update to the head you want to close and "hg commit --close". – jchadhowell Feb 23 '12 at 15:48
3

I think this is just what you're looking for: Keep My or Their files when doing a merge

It'll create new merge changesets that close down the "other" head w/o taking in any of its changes. You won't end up with a linear history but you'll end up with a single head.

Other inferior answers include using hg strip or hg clone -r to eliminate the heads/anonymous-branches you don't want. They're inferior because (a) if other clones exist you can't strip it doesn't work at all and (b) they throw away history which is the opposite of good version control practice -- even work you don't think you want now may be valuable someday.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • 1
    I don't think stripping as that inferior at all. Actually I wouldn't recommend an eliminating merge: the history graph would misleadingly indicate that the merged line is based on the eliminated branch. If there is a chance that a branch is needed later, keep it, or strip it otherwise. Tell your coworkers to also strip/reclone their repos. If one understands the collaboration related implications of stripping, it's okay to use it. Still, you can maintain a public streamlined (i.e. stripped) repo and an internal *dead end* repo, with branches you probably (but not for sure) don't need anymore. – Oben Sonne Dec 16 '10 at 19:36