Archive for December 2012

Four ways to do local lightweight (git-style) branches in Mercurial

One of the many git features that I miss in my day-to-day work using Mercurial is local lightweight branching. That is to say, branches that I don’t push to a public repository until I know they are in a sane state, and that do not take up any room in the public branch namespace.

Until recently, I thought the only ways to create a local branch that did not get pushed to a remote repository were to use multiple local clones or Mercurial Queues. Turns out there at least four ways to do local lightweight branches in Mercurial.

This is a bug, not a feature. I’m a Python programmer and a huge proponent of the “There should be one– and preferably only one –obvious way to do it.” rule. In git, the answer to pretty much every question is either, “create a branch” or “step 1: create a branch…”. Git branches are simple and elegant. Mercurial branches are… well, it depends what kind of branch you want. You do know what kind of branch you want, right?

That said, I’m forced to work in Mercurial, and until gitifyhg is working well enough for daily use, I’m constantly looking for ways to work around the shackles Mercurial places on me. Ironically, I know more about Mercurial extensions than many of my pro-hg colleagues, simply because as a git user, I know what’s missing and always studying to fill the gaps.

So, here are four methods of creating a lightweight local branch in Mercurial. I leave it to you to figure out which one is best for your workflow.

Local Clones

This is the most often suggested method of local branching in Mercurial, which is a shame because it’s ugly and reminiscent of subversion. Essentially, you simply make a new clone of the repository and work in there. If you like your changes, you push them, if not, you delete the directory.

I’ve experimented with a folder structure like this:

    - staging
    - feature1
    - bugfix1

Each of the subfolders is a mercurial clone of the project. Staging is a clone of upstream. feature1, bugfix1, and its siblings are clones of staging. I manage my commits from staging, pulling from upstream or from the local clones as needed.

How to make a “local branch”:

cd ..
hg clone staging featurename

How to commit changes to your “local branch”:

hg commit

How to delete a “local branch” if you don’t want it to see the light of day:

cd ..
rm -rf featurename

How to merge a finished feature and push upstream:

cd ../staging
hg pull -u # pull in upstream commits
hg pull ../featurename
hg hgview # see what's going on
hg merge # good luck


Most mercurial users I talk to recommend avoiding mercurial queues. I have no idea why, they are one of the most useful tools in the Mercurial toolbox. It does annoy me to be forced to learn an entirely different set of commands to manage patches before and after they are “made permanent”, but if you’re going to be working regularly in Mercurial, they are vital to maintaining the workflows you are used to from git.

Mercurial queues are simply a set of patches that have not yet been “commited”, with a collection of tools for managing them. Because the patches have not been committed, they can be reordered and rearranged for the best possible communication effect.

Steve Losh has written a great introduction to Mercurial Queues for git users. Chapter’s 12 and 13 of the hg book are more comprehensive guides, but can be hard to follow.

It is possible to push and pull queues (they are stored in a separate repository with the main mercurial repository), but if you actually want to share the unfinished code you’ve written, I think it’s better to either create a proper named branch and share it, or temporarily share your local repository with hg serve.

How to make a “local branch”:

hg qqueue --create feature

How to commit changes to your “local branch”:

hg qnew patchname # having to specify a name for each patch is annoying
hg qrefresh # update the most recent patch with your latest changes

You can also use hg qrecord instead of qrefresh to add specific changes, but it’s not as robust as git add -p (it doesn’t support splitting or editing hunks).

How to delete a “local branch” if you don’t want it to see the light of day:

hg qpop --all
hg qqueue patches # switch to the default queue
hg qqueue --delete feature

How to merge a finished feature and push upstream:

hg qfinish --applied


Mercurial users tend to recommend bookmarks when git users ask for lightweight branches. That doesn’t really work because all it does is give a temporary name to an anonymous head instead of a permanent one. If you push to the public repository, your branch will be pushed too, regardless if it was named, bookmarked or anonymous.

It turns out, Mercurial has a concept called phases, which allow you to mark a changeset as public, draft, or secret. Anything that has been pushed or pulled is considered public. All other local patches are draft by default, which means they will be pushed publicly when you call hg push. But if you set the phase of a patch to secret, that patch is not allowed to be pushed publicly.

The hgview extension is good for indicating what phase various commits are in.

How to make a “local branch”:

hg commit -m "initial commit to the feature"
hg bookmark feature
hg phase --force --secret feature

How to commit changes to your “local branch”:

hg commit # it's a normal mercurial commit, but now it's secret

How to delete a “local branch” if you don’t want it to see the light of day:

hg strip -rev "secret() and ancestors(feature)"

You’ll need the mercurial queue extension to get the strip command. You might want to double check that the revset I wrote is suitable for you; I’m not too clear on mercurial revsets yet.

How to merge a finished feature and push upstream:

hg phase --draft feature
hg push

Now, the interesting thing is that you can set secret phase on a named branch as well as a bookmark. So you can have locally modified named branches that don’t get pushed until you’re good and ready to push them, or never get pushed at all. Just replace bookmark with branch above.

I learned about phases today. I haven’t really used them in practice, yet, but I believe they will become my new favourite way to do local changes in Mercurial.

push -r

It is possible to tell mercurial to only push certain revisions to the upstream repository, thus keeping your other branches local. I wasn’t too keen on this at first because it seemed far too easy to accidentally push stuff I wasn’t ready to push. However, Mercurial does warn you before you push a new branch (anonymous or named), so as long as you have actually created a branch (rather than putting commits on top of the upstream branch), it will be quite safe.

To do this, simply pass the -r or --rev parameter when you hg push. For example, if you only want to push the default branch, pass --rev default and commits on any other branches will remain local.

How to make a “local branch”:

hg commit -m "initial commit to the feature"
hg branch feature

How to commit changes to your “local branch”:

hg commit # it's a normal mercurial commit

How to delete a “local branch” if you don’t want it to see the light of day:

hg strip -rev branch(feature)

How to merge a finished feature and push upstream:

hg commit -m "close feature branch" --close-branch
hg update default
hg merge feature
hg push --new-branch

How to push changes on default without pushing the new branch:

hg update default
hg push --rev default

You’ll notice that I used a named branch here. It’s possible to do the same thing with bookmarks or anonymous branches, but you would have to specify revision numbers manually and would probably have trouble defining revsets.

Bonus: qimport

This isn’t strictly to do with local branching, but it addresses another issue git users have with mercurial: rearranging commits on a branch that has never been published.

Mercurial users point to the rebase extension when we complain about this, but that extension is woefully inadequate compared to the usage we are used to in git. It can also be somewhat dangerous, unlike git’s version of rebase. I believe the rebase extension was written as a proof of concept in Mercurial, but because the documentation says “this is dangerous” nobody ever actually used it or added features to make it actually usable or safe.

However, there is another option: convert the commits to a mercurial queue and then use the relatively robust mqueue features to craft the changesets the way you want them to look. This is an important tool because it means you don’t have to decide in advance whether you want to use commits or patch queues for a particular feature. Just create a named branch, make your commits, and if you need to convert it to a queue, do so. This isn’t the place to explain the intricacies of Mercurial queues, but here’s a basic example of how to use them to remove patches from a named branch and append (rebase) them to default:

hg init .
hg view &  # Watch the changes in realtime as you type
echo a >> a
hg add a
hg commit -m "a"
hg branch feature
echo b > b
hg add b
hg commit -m "b"
echo c >> b
hg commit -m "c"
hg update default
echo a >>a
hg commit -m "aa"
hg qqueue --create feature
hg qimport --rev "branch(feature)"
hg qpop --all
hg update default
hg qpush --all
hg qfinish --applied

New Arch Linux Laptop Sticker Design

I’ve tweaked the design on the incredibly popular Arch Linux Laptop Stickers available through the Arch Linux Schwag store. I’ve taken the black outline of the sticker for both a more modern look and to alleviate problems when the decal cutters don’t quite line up with the border. I hope you like the effect!

My camera isn’t top of the line, so if someone would supply me some quality photos of these new stickers in action, I’d be happy to include them on the Arch Schwag website.

Thank you for supporting Arch Linux.I am always eager for new ideas to put in the Arch Schwag store. I’

Addressing mistakes I made in releasing Hacking Happy

When I released Hacking Happy two weeks ago, I made a rather serious mistake. It’s the first time I’ve self-published in eBook format. I put a lot of effort into thinking through the release and marketing of the book, but one problem slipped through.

I believe that when you purchase a digital product, you are purchasing the content, not the format. I released Hacking Happy as an eBook in four different formats, each available for download at a minimum purchase price of $5. This was the easiest way to make the book available on Gumroad, and I didn’t think about it much. I thought it would look good on the home page to have links to several different formats! However, I didn’t consider that someone may want copies of the book in two different formats. There are various reasons they may want to do this, and I do not believe they should have to pay full price for each of the different formats when they are essentially getting the same content.

Therefore, I have now made Hacking Happy available as a zip file of all four formats, in addition to the other download links. It is the same minimum price as the other links. However, this didn’t help anyone who had already supported me in buying the book in a single format. Luckily, Gumroad allows me to e-mail my buyers and I was able to supply them with a private link to the zipfile if they wish to access other formats.

Of course, since you own the content you purchased, you are welcome to convert it to other formats as you see fit!

The other issue people raised had more to do with marketing than the book itself. Part of the discussion on Hacker News pointed out that the excerpt didn’t really say much about what was in the book. I have alleviated this by adding a table of contents to the excerpt link on the home page and by choosing an excerpt from a chapter other than the introduction. I believe the chosen excerpt is representative of the contents of the book, and also highlights my writing style.

The response to this book has been very humbling. Other than complaints from people who chose not to purchase it, the feedback has been entirely positive. It has received one five star review on Amazon and I have received e-mails of support, congratulations, and gratitude. I knew when I wrote the book that it was necessary and would fill a niche, and I knew when I published it that I had done a good job. But the feedback reinforcing that knowledge has brought me as much happiness as the process of writing the book did!

This blog is not ad supported

I’m sick of the whining about internet ad blocking and the claims that it is or should be illegal.

This blog is not ad supported. It does track you, for which I hope you will forgive me, using WordPress Stats. If that bothers you — and it should — please install the ghostery extension. But it is not ad supported.

I believe this gives my visitors a better experience. Obviously, your experience is enhanced by the lack of distracting advertisements screen real estate being used to display things that are hopefully more valuable to you. But there’s more to it than that.

When you visit my blog, you can read each article on a single page. You don’t have to click through three “next page” links because someone wants to maximize their ad revenue. Further, my articles are (I hope) concise and to the point. I have no incentive to add irrelevant details to an essay in order to increase the number of pages you view. So you can read my thoughts and get on with your day.

More subtly, when you visit my blog, you can be sure that every article contains information that I consider to be valuable. I don’t write content-free essays with juicy titles to attract ad impressions. My visitors are not cattle whom I milk for ad revenue.

I started this blog over three years ago because Judd Vinet, founder of Arch Linux, had suggested I do so. I was just getting started in freelancing, and he said I’d be amazed how many clients can come out of a well-written technical post that happens to get top rating in Google. This has turned out to be true. In this light, the blog is itself an advertisement, showcasing my skills as a programmer, and more recently, as an author. Nowadays, I write articles, not so people will hire me (I’m actively hiding from head hunters), but so they will see those links to published books, gittip, and flattr on my sidebar.

I also write articles as a contribution to open source projects, both by promoting or introducing those projects to the few thousand visitors this blog receive per month, and by providing tutorials or instructions for them.

And I write because I can’t help writing. I am keenly aware of my audience, and thus the process is rather interactive. I write about things I believe you will find interesting. I want you to keep coming back, not just to use my open source projects, not just so you’ll tell you’re friends about my books, but because I want to keep writing articles you will read.

One of my more popular articles, bizarrely enough, has been the CSS popups are annoying rant I wrote three years ago. I notice that there are far fewer CSS popups today than there were back then. I’d love to take credit for that, though I have trouble being that vain. In that article, I suggested boycotting all websites that use CSS popups. Today I’d like to suggest a few additional actions we can take to stop advertising from ruining our internet experience:

  • Use adblock and ghostery. Not just to protect your privacy and improve your browsing experience, but to send a signal to the entire internet that you are a human being, not a product.
  • Avoid any site that display articles in multi-page format. I have a few worst offenders remapped to in my hosts file.
  • Avoid sites that consistently publish content-free posts with juicy titles.
  • Start supporting non-advertising income streams for individual content creators. This can range from financial contributions via sites like gittip or flattr to purchasing or subscribing to products the author has posted for sale to simply writing a review or recommendation promoting their product or content to other people.

I’d like to close with a message for you to pass on to those people whining that ad blocking cuts into their advertising revenue:

If your soul purpose in writing a blog is to make money off of ad revenue, stop writing and find a true passion. While you are making a few dollars or maybe a few hundred dollars a month off of Adsense, Google is making billions of dollars. Yes, you are being used, and yes, you are being cheated, but not by the visitors who are blocking your ads.

Advertising, especially targeted advertising, is a huge industry right now, but I believe and hope it is going to die. People are learning that word of mouth is a much more reliable way to discover a product than advertising. Businesses are switching from advertising to discovering subtle ways to manipulate users into doing the advertising for them. Further, people are becoming more educated about how big businesses are abusing them. I’m not the only one that is sick of being treated like a product instead of a customer.

Opterator, revisited

A few years ago, I wrote a simple decorator that introspects a main() method signature and docstring to generate an option parser. I never really used it, mostly because back then, I wasn’t too keen on third party dependencies. Nowadays with distribute being maintained, well-documented, and working (plus I know how to use it properly), I no longer have this concern.

A friend recently linked me to the brilliantly designed docopt and reminded me of my interest in opterator. I revisited my code and decided it’s a pretty neat little design. So I ported it to Python 3. This took a matter of minutes, largely because I originally wrote it shortly after taking the pytest tutorial at Pycon 2009 and it was easy to find the failing code. It now supports Python 2.6, 2.7, and 3.3, according to tox.

I originally designed opterator to be a full replacement for optparse and friends. However, my main purpose for it now is to create quick and dirty command line applications, often for my personal use. These apps usually have a couple of options and it doesn’t seem worth the trouble of setting up optparse. Yet, mucking around with sys.argv is also annoying. Opterator minimizes the boilerplate. Check out this basic example:

from opterator import opterate                      

def main(filename, color='red', verbose=False):     
    print(filename, color, verbose)


with three lines of boilerplate code, a function can be turned into a command line program that can be called like so:

  $ python examples/ this_file
  this_file red False

or so:

  python examples/ this_file --color=blue
  this_file blue False

or even so:

  $ python examples/ --color=purple another_file --verbose
  another_file purple True

And you even get a not totally (but somewhat) useless helpfile:

  $ python examples/ -h
  Usage: [options] filename

  -h, --help            show this help message and exit
  -c COLOR, --color=COLOR
  -v, --verbose

Building a Python Kivy App in Android (Easier than it looks, but harder than it needs to be)

When I introduced Kivy a while back, I mentioned that I had not been able to deploy a Kivy app on Android. I’ve managed to do this now, using the VirtualBox image provided by the Python For Android project. Using this image was substantially less work than trying to figure out how to install and set up all the prerequisites under Arch Linux. So here’s how to do it:

First download the VirtualBox image from Google Drive. Sadly I cannot find an adequate wget command to download this. Shame on you, Google!

You may want to double check the documentation to see if a later image has been made available.

It’s a big honkin’ file (1.4GB), so grab a cup of coffee, lunch, or go to bed, depending on your bandwidth and the current time of day.

Extract the file using p7zip. This takes a while, so you might want to grab another coffee:

7z e Python\ for\ Android\ -\ Ubuntu\ 12.04.7z

Make sure VirtualBox is installed and the kernel module is loaded. The commands on Arch Linux are:

pacman -S virtualbox virtualbox-host-modules
sudo modprobe vboxdrv

Fire up VirtualBox and hit Machine->Add.

Navigate to the folder the vbox image was extractedto. Select the Python for Android - Ubuntu 12.04.vbox machine and hit open.

If you have enough RAM, select the Python for Android machine and hit settings. Browse to the System tab and increase the RAM to a comfortable level (I set it to 2GB on my 4GB machine). You might also want to increase the number of processors and the video RAM. Hit Start to power on the machine.

Once Ubuntu has loaded, review the README for some important information. You may want to update the VirtualBox Guest Additions install, although I’m sure it will work fine without it.

Now you’re ready to build an APK from a Python project. Open a terminal from the menu on the sidebar. The first thing you’ll want to do is update the python-for-android project to the latest git checkout. This is a bit messy because there are a couple edits in the current checkout that were later fixed upstream. So you’ll want to stash the changes before pulling:

cd android/python-for-android
git stash
git pull
git stash apply

Unfortunately, this introduces a merge conflict in The upstream project has made some of the customizations obsolete by including more generic code. Luckily, it’s a trivial fix. Open in an editor (gedit works, but I used vim.) and search for the characters =======. It’s at line 170. Delete the line above that says <<<<<<< Updated upstream. Leave the export line that was above the =======. Then delete the ======= and >>>>>>> Stashed changes and the outdated export line in between. Save the file and close the editor.

Now you need a Kivy application to install. Presumably you’ve written your own, but for this example, I’m going to use a cool one supplied by the Kivy team. The Kivy Remote Shell creates an ssh server on the phone that allows you to log in from your computer over ssh and execute Python commands on the phone. You can even run Java commands using the beta pyjnius connector.

These commands will prepare a python for android distribution ready for installation:

cd ..
git clone git://
cd python-for-android
./ -m 'openssl pycrypto pyasn1 pyjnius twisted kivy'

This will prompt to see if you want to overwrite the previous python for android distribution. Press <enter> to do so. Give it some time to connect to the network, download the dependencies from Pypi, and compile them.

Now you need a rather ugly command to actually build the apk. The options are summarized in the Python for Android documentation.

cd dist/default
./ --package org.kivy.sshshell --name "Kivy Remote Shell" \
  --version 1 --dir ../../../kivy-remote-shell/ \
  --icon ../../../kivy-remote-shell/icon.png --permission INTERNET debug

This will create the file bin/KivyRemoteShell-1-.debug.apk. Now let’s install it to the phone! First make sure USB debugging is enabled on your phone. Go to the Settings-->Developer Options menu and make sure Developer Options are enabled and that Android Debugging is enabled.

Plug the phone into your computer via the USB cord. Click the little “USB” icon in the VirtualBox status bar and check the box next to the name for your phone.

Run the command ~/android/android-sdk-linux_x86/platform-tools/adb devices to make sure it outputs the identifier of your phone. If it works, simply run ~/android/android-sdk-linux_x86/platform-tools/adb install bin/KivyRemoteShell-1-debug.apk to install the app.

(If you can’t get the phone to connect to the VM, you can also copy the .apk to the host machine to install it. Use VirtualBox’s shared folders feature).

You can now shut down the virtual machine from Ubuntu’s shutdown menu. For security, it’s a good idea to turn off USB debugging on your phone until you need it again. Run the “Kivy Remote Shell” app that is now in your phone’s app drawer. Type the command that comes up onto your screen into a terminal on your computer, and you will have access to a Python prompt running on your phone!

This same process can be used to install self-developed Kivy apps to your phone. Congratulations!

Hacking Happy

I am extremely proud to announce the release of my new book, Hacking Happy. I believe every geek should read this book to help them find the joy and happiness in their lives that I have in mine.

The foundations of this book started with a hospital stay, as I outlined a couple of months ago. It was on the psychiatric ward that I started learning about the skills that ultimately led to my recovery. These techniques are as learnable as any programming language. My book helps you discover them for yourself.

Hacking Happy will motivate you to find techniques that work for you to optimize the happiness levels in your life. It is not a book of ready-made solutions. It is a true hacker’s manual. It provides processes. You find the solutions for the system you are hacking: yourself. The entire book is a series of analogies (some suitable, others simply amusing) to common software and systems development situations. However, the systems presented have been scientifically proven by psychologists and psychiatrists.

I have to admit that about halfway through writing Hacking Happy, I decided not to publish it. It seemed corny and the tools I was describing appeared so obvious to me. I couldn’t see how anyone would pay to read it. Then I asked myself, “If they are so obvious, why did it take me two decades and several mental breakdowns to find them?”

So I rewrote the book. It is now the best writing and most important work I have created, yet. It is hilarious. It is motivating, moving, and inspiring. It is educational and instructive. It is essential.

Marketing is a skill I’m still trying to learn. So I’m turning to you, “the crowd” to help market it! If you don’t buy the book, at least share it. Tell your friends about it. Retweet it. Like it. Plus One it. I think “Hacking Happy” is vital reading for every coder and systems professional out there. If you don’t love yourself completely and unconditionally, buy this book.

Hacking Happy is available in print and eBook formats. I’ll be adding more links to the home page as it propagates to more retailers. As of today, you can buy the book in print from CreateSpace or, or download eBooks in the following formats:

Gitifyhg: Accessing Mercurial repos from GIT

My company uses Mercurial for internal hosting. Other than that, it’s an absolutely terrific place to work.

About three quarters of my colleagues are sick of hearing the rest of us complain about Mercurial’s inadequacies. They mention tutorials like this one that simply don’t work in real life. I’ve done my research, and I have not been able to find a viable git to hg pipeline anywhere. There is a git-hg repo, but it appears to be un-maintained and not overly well documented. It’s also written in bash, so I’m not eager to take over maintenance.

Instead, I’ve been spending some of my non-working hours trying to make a python wrapper around hg-git named gitifyhg. It started out as an automated version of the hg-git tutorials, but is now expanding to provide additional support and tools.

Right now I’m following a git-svn style of workflow, where your git master branch can be synced up with the hg default branch. It seems to be working somewhat ok. I think at this point, the pain of using gitifyhg is about equal to the pain of using hg alone. Hopefully future improvements will reduce that pain, and as always, patches are most welcome!

The instructions are pretty clear and the unit tests provide a pretty good description of basic usage. Non-basic usage probably doesn’t work (yet). Here’s a tutorial of what does work:

Acme corporation uses Mercurial for all their repositories. Fred and Wilma are developing a project named AcmeAdmin together. Fred is content to use Mercurial for hosting, but Wilma is a git advocate who is going crazy with the restrictions Mercurial places on her. She decides she’s going to try gitifyhg on this new project to see how much trouble it is.

Fred starts the project by creating a Mercurial repo that will serve as the remote repo for both of them:

mkdir acmeadmin
cd acmeadmin
hg init

Fred and Wilma are doing a very strange sort of pair programming where they have separate repositories on the same machine. They are doing this so if you were reading along, you could type in the same commands they are typing and the demo would work. Rest assured that in spite of this queer practice, Fred and Wilma are hotshot programmers. So Fred now clones this remote repo and starts working. In the meantime, Wilma is browsing the gitifyhg README, so she hasn’t cloned anything yet.

cd ..
hg clone acmeadmin fredacme
cd fredacme
echo "Write Documentation" >> TODO
hg add TODO
hg commit -m "write the documentation for this project."
echo "Write Unit Tests" >>TODO
hg commit -m "unit tests are done"
hg push

Wilma’s caught up now and eager to try gitifyhg. She takes over the keyboard and clones the remote repository, which already contains Fred’s changes. Then she runs gitifyhg and verifies that a git repository exists with Fred’s two commits.

cd ..
hg clone acmeadmin wilmaacme
cd wilmaacme
git log

Fred’s gone for coffee. Wilma now starts her own hacking and pushes the commits using gitifyhg.

echo "Implement code until tests pass" >>TODO
git commit -m "code implemented" -a
git hgpush

Wilma got kind of lucky here because she implemented her code on the master branch and there were no conflicts with Fred’s work. If there had been, I’m not sure what would have happened. Fred’s finished his coffee and pulls in Wilma’s change via Mercurial. He then commits some more changes.

cd ../fredacme
hg pull -u
echo "deploy" >> TODO 
hg commit -m "it's up and running"
hg push

Meanwhile, Wilma is working on a separate feature. She remembers to create a new git branch this time, which is good because she’s going to want to do some rebasing when Fred’s commit comes in.

cd ../wilmaacme
git checkout -b feature_branch
echo "new feature documentation" >> FEATURE
git add FEATURE
git commit -m "start new feature by documenting it"

Before pushing her changes, Wilma pulls to see if Fred has done anything. He has! But the hgpull merges all that into her master branch. She checks out her working branch and rebases it onto master. Then she pushes it upstream.

git hgpull
git checkout feature_branch
git rebase master
git checkout master
git merge feature_branch
git hgpush

And that’s the basic workflow! I’m probably going to add an hgrebase command to take care of that checkout rebase checkout merge step, since I expect it to be common. It should probably use git rebase -i, which is probably the most amazing thing that ever happened to version control.

Like I said, this is how gitifyhg works when all goes well. When things don’t go well it’s still a bit of a mess. I’ve had to manually sync up the hg and git working directories using git reset --hard and hg update -C a couple times. Once, my hgpush ended up putting a bookmarked branch on my hg repo that I didn’t want to go public (luckily, hg push fails by default when there are multiple heads); I ended up having to use hg strip to clean it up. I’m hoping to automate or prevent some of this in the future. For now, try it out and submit patches or at least issues!