Is there a downside to this Mercurial workflow: named branch “dead” head?

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?”

  • How to setup a git structure where a submodule requires an external library underneath it?
  • How to merge my local uncommitted changes into another Git branch?
  • Git flow - get rid of a particular feature
  • Is there an intelligent 3rd merge tool that understands VB.NET
  • What's the ideal git branching strategy for this product development?
  • Can a branch be made from a previous changeset?
  • 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.

  • SVN: Moving repository trunk to another's branch (with history)
  • GIT: How to protect the branch from being removed by other developers?
  • Is there an (open source) VCS that can work with a whitelist instead of a blacklist?
  • git removing commit history of some files from a branch
  • create a git repo for project skeleton
  • Subversion or Mercurial SPI - What API shall a server implement?
  • 3 Solutions collect form web for “Is there a downside to this Mercurial workflow: named branch “dead” head?”

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

    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?

    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.


    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.

    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 ( 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.

    Git Baby is a git and github fan, let's start git clone.