5

I love the flexibility of named branches but I have some concerns about the prolifieration of heads.

Even when the branch is closed, it still shows up in the heads. I have an idea for how to clean up the output from "hg heads" My question to the gurus: "What am I missing?"

First off you may ask, Why might I want to totally hide the head of a named branch? For various reasons:

  • the feature is a bad idea
  • the feature is a good idea that is not ready for merging to tip, but maybe in a few months
  • the branch is a patch release to an older tagged version

edit: It turns out the prolifiration of heads is a symptom of the older version of mercurial I was using. Closing the branch hides the head of the branch it on newer Mercurial versions.

My idea is to have a "dead" head branch onto which all these closed branch heads will be merged.
The dead head would be parented by changeset 0 and serve the sole purpose of bundling up the stray heads that are not needed right now.

The deadhead has only other deadhead children, which never get merged back into the default branch.

Mark Borgerding
  • 8,117
  • 4
  • 30
  • 51

3 Answers3

7

You can use hg commit --close-branch to mark a branch as closed:

http://www.selenic.com/mercurial/hg.1.html#commit

Closed branches will not show up in hg branches or hg heads by default (only if the -c/--closed option is specified), so I'm not sure how you're seeing "clutter"?

What exactly would you gain by merging things?

Amber
  • 507,862
  • 82
  • 626
  • 550
  • True enough that closing the branch stops it from showing up in hg branches, but it still shows up in the heads. – Mark Borgerding Sep 03 '10 at 19:56
  • Aha! I just realized that on newer versions of hg, the closed branch heads *ARE* hidden. So my "dead head" solution is overkill for a temporary problem. FYI. With version 1.3.1 the closed branches are incorrectly shown in "hg heads", in 1.5.1 they are correctly hidden. – Mark Borgerding Sep 03 '10 at 20:04
1

There seems to be a downside to leaving dead heads which is not solved by later versions of Mercurial.

Suppose you have a lot of closed branch heads and only a single non-closed active branch. Suppose further that at some later point you make a bad commit (rev bad) on top of the non-closed head (rev good). Before you push you'd like to clone your repository dropping that bad commit. That is usually a simple thing to do - 

hg clone --rev good BadRepo FixedRepo

This unfortunately does not pull the closed branch heads since they are not ancestors of rev good. All those branches which were closed will not be closed in the cloned repository. I tested this with Mercurial 2.3.1.

Thoughts?

p.s. The hgflow extension does close feature and release branches before merging. This avoids the closed heads problem.

Regarding the clone being an ugly approach, it has worked quite well and easily for me. The clone replaces the repository with the bad commit. The clone is a local effort. That bad repository is just discarded. I usually realize I've made a bad commit very soon after.

The -b option is just a way to rephrase the --rev by using a branch name instead of a change set identifier. Using the --rev option does pull the entire topological tree under the revision. If the revision is the head of the branch then the --rev clone is the same as the -b clone. -b leaves the same problem that I described with the --rev option. Branches which were closed in the original repository get reopened if they were left as heads.

If the pattern is to leave closed heads then they will soon greatly outnumber relevant heads. Getting those closures into a clone is quite an effort unless you do a full clone.

user1804642
  • 11
  • 2
  • 1
    remove bad commit by clone is **horribly ugly** method. And even with clone you can use -b with all closed branches – Lazy Badger Nov 07 '12 at 01:40
0

I feel I've muddied the waters with why I might do a partial clone. I'll restate my concern about closure heads more carefully.

For any partial clone from repository X to repository Y, if there exists a branch B in repository X with a closure head and that branch is included in the clone for purely topological reasons, then branch B will not be closed in repository Y. Further if the merging pattern is to generally leave closure heads then the number of closure heads is of order development time.

This is a concern to me so I close my branches before I merge. I use hgflow (http://nvie.com/posts/a-successful-git-branching-model). A possible partial clone would be to clone the development branch and follow that with a pull of the master branch (e.g. if you wish to eliminate dead ends). If feature and release branches had been closed after their final merges then those branches would be reopened in the clone.

user1804642
  • 11
  • 2