0

While cleaning up a certain Hg (Mercurial) repository, I noticed that an old revision (actually 4 years old) shows a branch going nowhere on the default branch.

I thought it wasn't possible to branch the same branch (I mean, you can have a new head on a new branch, but not on the same branch). What is happening here and what did the (then working for me) programmer do here incorrectly, and more importantly, how to prevent it?

enter image description here

Abel
  • 56,041
  • 24
  • 146
  • 247
  • @downvoters: care to comment what is unclear/wrong about my question? Suggest edit? (I improved the title, maybe that helps, it was quite awkward) – Abel Jan 12 '17 at 11:34
  • 1
    I did not downvote, but I will point out that in Mercurial terms, that's not a *branch*, it's merely a *head*. In Mercurial, any commit with no descendants is a head, by definition. The way you create one is to make a new commit. If the *current* commit *was* a head, making the new commit causes the previous head to become a non-head, leaving the number of heads unchanged. If the current commit was a non-head, the number of heads has just increased by 1. That's all there is to it. – torek Jan 12 '17 at 12:16
  • Typically, by the way, the origin of these heads is a push rather than a commit—and yes, hg encourages you to notice that this would increase the number of heads, and to do something different, but it's easy to do it anyway. – torek Jan 12 '17 at 12:18

1 Answers1

2

It always has been possible (or at least since mercurial around 0.9); mercurial is not git where such thing is much more complicated to handle. You can work without any (named) branches in mercurial and have as many anonymous heads per branch as you care to create. Simply update to a non-head version and start to commit and - voilà - you created a new head.

EDIT to add: You can prevent adding additional heads to your repository if you apply an appropriate pretxnchangegroup hook which checks for the presence of additional heads in the incoming changesets. There are a couple of old stackoverflow answers to that:

How do I prevent someone from pushing multiple heads?

How can I create a mercurial hook that prevents new heads?

to name just two

Community
  • 1
  • 1
planetmaker
  • 5,884
  • 3
  • 28
  • 37
  • But if I do that I get a message saying "not a head revision, use --force", or something similar. So that is probably what the programmer did at the time, _forced_ his commit on a non-head revision of the central repository? – Abel Jan 12 '17 at 11:33
  • Basically, once something like this happens it becomes very unclear what the intent was, let alone to do a sane and safe merge. Or am I misunderstanding some basics of Hg here? – Abel Jan 12 '17 at 11:35
  • I don't see how that obscures the intent - it all depends on the commit messages though and whether you care to read the code. Concerning merging: a head is a head is a head. No matter where it sits; merge rules don't depend on whether heads are in the same named branch or not. Actually it's discouraged to use too many different named branches, especially not one for every single fix – planetmaker Jan 12 '17 at 12:12
  • Anyhow, using a different head for, say, a single bug-fix, maybe even pushed from somewhere else, a laptop when travelling, is not necessarily 'wrong'. It depends on how you care to use the system and shape your workflow – planetmaker Jan 12 '17 at 12:23
  • Thanks for these extra comments and the updates to your answer, it gives me a better understanding of hg in general and how it can be used, esp wrt my misunderstanding of multiple heads in a branch. – Abel Jan 13 '17 at 11:31