Using named branches (`hg branch`) for feature branches isn't recommended.

[Peter Bourgon]

> Each commit has a field for what branch it's part of, just like a date
> or username. And just like date and username, these fields are
> immutable. Thus, a named branch is simply the collection of all commits
> that have the same branch field.

This is useful information that I was not previously aware of. Thanks.

> If you want anonymous branches, you don't need to actually _do_
> anything, it's a natural part how Mercurial works. Let's say we start
> with:
>  . . .
> At this point Alice can be said to have "two anonymous branches", with
> heads at "g" and "i". But when were these "branches" created? Any time
> you create a new commit, you are potentially creating a new "branch"
> relative to some other user. This is a fundamental part of how a
> distributed SCM works.

Yes, I understand this perfectly. But this "split" in history required
specific, simultaneous action from multiple actors on the same
repository. And, it produces a undesirable (from a user-perspective)
side-effect: when Charles runs "hg pull ; hg update default", his
working directory represents whichever of Alice or Bob's lineage
happened to have the most recent update.

The behavior I want is perhaps not well described as an anonymous
branch. Maybe the better term is "secondary branch" or "hidden
branch." If the default branch has an existing history

  a-b-c-d-e

in a central repo, Alice would run some operation that causes her next
commits to be part of a new "hidden branch"

  a-b-c-d-e
               `-f-g-h

The only difference between this "hidden branch" I'm imagining and the
current behavior is that when Alice pushes, and Bob pulls and updates,
Bob's working directory is still at changeset e. He must manually
specify f, g or h to get to Alice's changes; at no point would "hg
update default" ever switch to that lineage.

(I understand that I can simulate this behavior with bookmarks. But
it's at the cost of violating #2, and introducing a new moving part in
our SCM that needs to be managed, and that developers need to be aware
of.)

Named branches give me exactly the behavior I want, seem to work
great, and are easy to understand by everyone on my team. But I hear
people saying things like in the Subject: often enough that it vexes
me a bit.