Renaming a Mercurial branch with the evolve extension

Short version (rename from $OLD to $NEW):

ROOT="$(hg id -qr 'first(roots(branch('$OLD')))')"
MSG="$(hg log -r $ROOT -T '{desc}')"  

hg update $ROOT
hg branch $NEW
hg commit --amend -m "$MSG"
hg evolve --all

Mercurial records in which named branch a commit was created. This can be inconvenient when you choose temporary branch names like "foo" or "justworkdamnit".

The evolve extension enables safe, collaborative history editing which removes this inconvenience while preserving the reliability guarantees of Mercurial.

Here I show in a quick example how to rename a branch in Mercurial using the evolve extension.

You can use this method for all changes which you did not transfer elsewhere yet (they must be in draft or secret phase).

Note (2016): The evolve extension is still in testing. Do not use it for production yet. If you want to help stabilizing it, please join evolve-testers. I’ve been using it for more than a year, but I know how to fix things when I hit a bug in the evolve extension.

Conveniently merge a NEWS file without conflicts

Writing a NEWS file (a list of changes per version, targeted at end-users) significantly reduces the effort for doing a release: To write your release notes, just copy the latest entries from the NEWS file into a message. It is one of the gems in the GNU coding standards: Simple yet extremely useful. (For a detailed realization, refer to the Perl Specification for CPAN Changes files.)

However when you’re developing features in parallel, for example by using a pull-request workflow and requiring contributors to update the NEWS file, you will often run into merge conflicts. Resolving these takes time, though the resolution is trivial: Just use the lines from both heads.

To resolve the problem, you can set your version tracking system to use union-merge for NEWS files.

BitBucket got big on Mercurial — until they got bought by Atlassian

A comment on largefile support missing in BitBucket, despite being a much-requested feature since 2012.

Note that it’s not Atlassian which got big with Mercurial. It’s Bitbucket which got big with Mercurial, and it was later bought by Atlassian.

Real Life Infocalypse

Freenet Logo: Follow the Rabbit DVCS in the Darknet. The decentralized p2p code repository.

In this guide I show by example how you can use the Infocalypse plugin for distributed development without central point of failure or reliance on unfree tools.12

If you think “I have no idea what this tool is for”: Infocalypse gives you fully decentralized Github with real anonymity, using only free software.

# freenet -> local
hg clone freenet://ArneBab/life-repo
# local -> freenet
hg clone life-repo real-life
hg clone real-life freenet://ArneBab/real-life
# send pull request
cd real-life
hg fn-pull-request --wot ArneBab/life-repo
(enter message)
# check for pull-requests
cd ../life-repo
sleep 1800 # (wait for confidential delivery)
hg fn-check-notifications --wot ArneBab

If you like this, please don’t only click like or +1, but share it with everyone who could be interested. The one who knows best how to reach your friends is you — and that’s how it should be.

  1. This guide shows the convenient way of working which has a higher barrier of entry. It uses WoT Pseudonyms to allow you to insert repositories by Pseudonym and repository name. If you can cope with inserting by private key and sending pull-requests manually, you can use it without the WoT, too, which reduces the setup effort quite a bit. Just skip the setup of the Web of Trust and Freemail and plugins. You can then clone the life repo via hg clone freenet://USK@6~ZDYdvAgMoUfG6M5Kwi7SQqyS-gTcyFeaNN1Pf3FvY,OSOT4OEeg4xyYnwcGECZUX6~lnmYrZsz05Km7G7bvOQ,AQACAAE/life-repo.R1/4 life-repo. See hg fn-genkey and hg help infocalypse for details. 

  2. Infocalypse shows one of many really interesting possibilities offered by Freenet. To get a feeling of how much more is possible, have a look at The Forgotten Cryptopunk Paradise

git vs. hg - offensive

In many discussions on DVCS over the years I have been fair, friendly and technical while receiving vitriol and misinformation and FUD. This strip visualizes the impression which stuck to my mind when speaking with casual git-users.

Update: I found a very calm discussion at a place where I did not expect it: reddit. I’m sorry to you, guys. Thank you for proving that a constructive discussion is possible from both sides! I hope that you are not among the ones offended by this strip.

To Hg-users: There are git users who really understand what they are doing and who stick to arguments and friendly competition. This comic arose from the many frustrating experiences with the many other git users. Please don’t let this strip trick you into going down to non-constructive arguments. Let’s stay friendly. I already feel slightly bad about this short move into competition-like visualization for a topic where I much prefer friendly, constructive discussions. But it sucks to see contributors stumble over git, so I think it was time for this.

»I also think that git isn’t the most beginner-friendly program. That’s why I’m using only its elementary features«

git vs. hg - offensive

To put the strip in words, let’s complete the quote:

That’s why I’m using only its elementary features«
<ArneBab> I hear that from many git-users…
»oh, maybe I should have another look at hg after all«

Why this?

Because there are far too many Git-Users who only dare using the most basic commands which makes git at best useless and at worst harmful.

This is not the fault of the users. It is the fault of the tool.

This strip is horrible!

If you are offended by this strip: You knew the title when you came here, right?

And if you are offended enough, that you want to make your own strip and set things right, go grab the source-file, fire up krita and go for it! This strip is free.1


If you feel that this strip fits Mercurial and Git perfectly, keep in mind, that this is only one aspect of the situation, and that using Git is still much better than being forced to use centralized or proprietary version tracking (and people who survive the initial phase mostly unscarred can actually do the same with Git as they could with Mercurial).

  1. All the graphics in this strip are available under free licenses: creative-commons attribution or GPLv3 or later — you decide which of those you use. If it is cc attribution, call me Arne Babenhauserheide and link to this article. You’ll find all the sources as well as some preliminary works and SVGs in git-vs-hg-offensive.tar_.gz or (whichever you prefer)

    cc by GPLv3

Factual Errors in “Git vs Mercurial: Why Git?” -- and corrections shown by example

Update 2016: Instead of fixing the article, the Atlassian web workers removed the comments which point out the misinformation in the article. *sigh*


In the Atlassian Blog, a Git proponent spread blatant misinformation which the Atlassian folks are leaving uncommented even though the falseness has been shown by multiple people and even in examples in the article itself.

The claims and corrections:

  • Claim: Git never loses unreferenced data. Mercurial needs special handling to retrieve unreferenced data. Reality: Due to automatic garbage collection, history editing in git unpredictably loses unreferenced history while Mercurial stores permanent backups which can be retrieved with core commands.
  • Claim: Only git branches are namespaced. Reality: Mercurial bookmarks are namespaced with bookmark@path, when there could be confusion. This is equivalent to git’s use of path/branch, but only used where it is needed, while git forces the user to always make that distinction.
  • Claim: Only git can provide a staging area. Reality: Activating mercurial queues (mq) and the record extension provides a staging area like the git index — for those who want it.
  • Claim: Git is more powerful. Reality: Both have the same raw power (as proven by transparent access with Mercurial to Git repos via hg-git), but
  • its “cuddly command line” gives Mercurial an efficiency during actual usage which most people do not find in Git.

2 years ago, Atlassian developer Charles O’Farrell published the article Git vs. Mercurial: Why Git? in which he claimed to show "the winning side of Git”. This article was part of the Dev Tools series at Atlassian and written as a reply to the article Why Mercurial?. It was spiced with so much misinformation about Mercurial (statements which were factually wrong) that the comments exploded right away. But the article was never corrected. Just now I was referred to the text again, and I decided to do what I should have done 2 years ago: Write an answer which debunks the myths.

“I also think that git isn’t the most beginner-friendly program. That’s why I’m only using its elementary features” — “I hear that from many git-users …” — part of the discussion which got me to write this article

Basic usecases for DVCS: Workflow Failures

If you came here searching for a way to set the username in Mercurial: just run hg config --edit and add
    username = YOURNAME <EMAIL>
to the file which gets opened. If you have a very old version of Mercurial (<3.0), open $HOME/.hgrc manually.

Update (2015-02-05): For the Git breakage there is now a partial solution in Git v2.3.0: You can push into a checked out branch when you prepare the target repo via git config receive.denyCurrentBranch updateInstead, but only if nothing was changed there. This does not fully address the workflow breakage (the success of the operation is still state-dependent), but at least it makes it work. With Git providing a partial solution for the breakage I reported and Mercurial providing a full solution since 2014-05-01, I call this blog post a success. Thank you Git and Mercurial devs!

Update (2014-05-01): The Mercurial breakage is fixed in Mercurial 3.0: When you commit without username it now says “Abort: no username supplied (use "hg config --edit" to set your username)”. The editor shows a template with a commented-out field for the username. Just put your name and email after the pre-filled username = and save the file. The Git breakage still exists.

Update (2013-04-18): In #mercurial @ there were discussions yesterday for improving the help output if you do not have your username setup, yet.

1 Intro

I recently tried contributing to a new project again, and I was quite surprised which hurdles can be in your way, when you did not setup your environment, yet.

So I decided to put together a small test for the basic workflow: Cloning a project, doing and testing a change and pushing it back.

I did that for Git and Mercurial, because both break at different points.

I’ll express the basic usecase in Subversion:

  • svn checkout [project]
  • (hack, test, repeat)
  • (request commit rights)
  • svn commit -m "added X"

You can also replace the request for commit rights with creating a patch and sending it to a mailing list. But let’s take the easiest case of a new contributor who is directly welcomed into the project as trusted committer.


A slightly more advanced workflow adds testing in a clean tree. In Subversion it looks almost like the simple commit:


Test of the hg evolve extension for easier upstreaming

1 Rationale

PDF-version (for printing)

orgmode-version (for editing)

repository (for forking)


hg evolve might offer that.


A complete Mercurial branching strategy



Summary: 3 simple rules


3 simple rules:






Overview Diagram

Table of Contents

Practial Actions


  • Regular development



  • Feature Branches





  • Tasks for Maintainers

    • Initialize (only needed once)

      • create the repo: hg init reponame; cd reponame


















Creating nice logs with revsets in Mercurial


Update: Since Mercurial 2.4 you can simply use
hg log -Gr "branchpoint()"



This article shows examples for this.

Mercurial Workflow: Feature seperation via named branches

Also published on Mercurials Workflows wikipage. Originally written for PyHurd: Python bindings for the GNU Hurd.

For Whom?

If you

  1. want to develop features collaboratively and you want to be able to see later for which feature a given change was added or
  2. want to do changes concurrently which would likely affect each other negatively while they are not finished, but which need to be developed in a group with minimal overhead,

then this workflow might be right for you.

Note: If you have a huge number of small features (2000 and upwards), the number of persistent named branches can create some performance problems for listing the branches (only for the listing!) (as different example, pushing is unaffected: Linear history is just as fast as 2000 branches). For features which need no collaboration or need only a few commits, this workflow also has much unnecessary overhead. It is best used for features which will be developed side by side with default for some time (and many commits), so tracking the default branch against the feature is relevant. To mark single-commit features as belonging to a feature, just use the commit message.

Note: The difference between Mercurial named branches and git branches is that git branches don’t stay in history. They don’t allow you to find out later in which branch a certain commit was added. If you want git-style branching, just use bookmarks.

Note: If you avoid using stable as branch name, you can always upgrade this workflow to the complete branching model later on.

Learning Mercurial in Workflows

The official workflow guide for Mercurial, mirrored from License: GPLv2 or later.

It delves into nonlinear history and merging right from the beginning and uses only features you get without activating extensions. Due to this it offers efficient and safe workflows without danger of losing already committed work.

Infocalypse - Make your code survive the information apocalypse

Anonymous DVCS in the Darknet.

This is a mirror of the documentation of the infocalypse extension for Mercurial written by djk - published here with his permission. It is licensed solely under the GPLv2 or later. The text is long. For concise information, use the second Link above (Freenet Development over Freenet).


The Infocalypse 2.0 hg extension is an extension for Mercurial that allows you to create, publish and maintain incrementally updateable repositories in Freenet.

Your code is then hosted decentrally and anonymously, making it just as censorship-resistant as all other content in Freenet.

It works better than the other DVCS currently available for Freenet.

Most of the information you will find in this document can also be found in the extension's online help. i.e.:

hg help infocalypse

Track your scientific scripts with Mercurial

If you want to publish your scientific scripts, as Nick Barnes advises in Nature, you can very easily do so with Mercurial.

All my stuff (not just code), excempting only huge datasets, is in a Mercurial source repository.1

Whenever I change something and it does anything new, I commit the files with a simple commit (even if it’s only “it compiles!”).

  1. Mercurial is free software for versiontracking: 

writing together – collaborative editing is easy

→ comment to The next wave in scholarly word processors?

What I’d like to see is more people using version tracking systems.

With these you have a discussion which can be merged easily when it gets branched. I use it for anything I do, and I could use it together with an only-windows-and-GUI user with ease, installing TortoiseHG for both and Lyx for him (LaTeX made easy – you don’t have to see the sources).

Internet, community cloud foo and control of my own data


What I miss in the internet is the notion of being able to control what my apps access for data.

Why can’t a chat application just connect to a neighborhood- or community-server, and why can’t the activity-stream come from the people I know — and query only their systems, like jabber does?

Almost all geolocation services should be implementable over direct friend-to-friend connections like jabber, and I don’t really see why my local program can’t also get the news from my local jabber contacts.

A short introduction to Mercurial with TortoiseHG (GNU/Linux and Windows)

Note: This tutorial is for the old TortoiseHG (with gtk interface). The new one works a bit differently (and uses Qt). See the official quick start guide. The right-click menus should still work similar to the ones described here, though.

Downloading the Repository

After installing TortoiseHG, you can download a repository to your computer by right-clicking in a folder and selecting the menu "TortoiseHG" and then "Clone" in there (currently you still need Windows for that - all other dialogs can be evoked in GNU/Linux on the commandline via "hgtk").

Right-Click menu, Windows:


workflow concept: automatic trusted group of committers


A workflow where the repository gets updated only from repositories whose heads got signed by at least a certain percentage or a certain number of trusted committers.


Mercurial, two hooks for checking and three special files in the repo.

The hooks do all the work - apart from them, the repo is just a normal Mercurial repository. After cloning it, you only need to setup the hooks to activate the workflow.

Extensions: gpg

Hooks: prechangegroup and pretxnchangegroup

Kurze Einführung in Mercurial mit TortoiseHG (GNU/Linux und Windows)


Das Repository herunterladen

Wenn du TortoiseHG installiert hast, kannst du dir das Repository auf den Rechner laden, indem du in einem Ordner rechtsklickst und im Menü "TortoiseHG" die Option "Clone" wählst (Aktuell brauchst du für den Dialog noch Windows, die anderen gibt es auch in GNU/Linux).

Rechtsklick-Menü, Windows:


Clone, GNU/Linux:


Gentoo live ebuild for Mercurial

We (nelchael and me) just finished a live ebuild for Mercurial which allows to conveniently track the main (mpm) repo of Mercurial in Gentoo.

To use the ebuild, just add

=dev-util/mercurial-9999 **  

to your package.keywords and emerge mercurial (again).

Anonymous code collaboration with Mercurial and Freenet

Anonymous DVCS in the Darknet.

There is a new Mercurial extension for interaction with Freenet called "infocalypse" (which should keep working after the information apocalypse).

It offers "fn-push" and "fn-pull" as an optimized way to store code in freenet: bundles are inserted and pulled one after the other. An index tells infocalypse in which order to pull the bundles. It makes using Mercurial in freenet far more efficient and convenient.

Also you can use it to publish collaborative anonymous websites like the freefaq and Technophob.

And it is a perfect fit for the workflow automatic trusted group of committers.

Otherwise it offers the same features as FreenetHG.


Mercurial is a distributed source control management tool.

Mercurial links:
- Mercurial Website.
- - Easy repository publishing.
- Hg Init - A very nice Mercurial tutorial for newcomers.

With it you can save snapshots of your work on documents and go back to these at all times.

Also you can easily collaborate with other people and use Mercurial to easily merge your work.

Mercurial for two Programmers who are (mostly) new to SCM

Written in the Mercurial mailing list

Hi Bernard,

Am Dienstag 03 Februar 2009 20:19:14 schrieb ... ...:
> Most of the docs I can find seem to assume the reader is familiar with
> existing software developemnt tools and methodologies.
> This is not the case for me.

It wasn't for me either, and I can assure you that using Mercurial becomes
natural quite quickly.

Mercurial vs. Bazaar speedtest clone and log - update: 4 runs with different versions

Some folks in #mercurial @ just repeated the tests, so we have now a bit more stable data.

The evaluation shows the following:

  1. Initial clone: hg is about 4.4 times faster (about 2 min vs. 6 to 15 min)
  2. Repository sizes: the hg repo is about 1.92 smaller (~113M vs. 215M)
  3. Time for a full log: hg is about 2.36 times faster (~21s vs. ~50s)
  4. Time for annotating Misc/NEWS: hg is 1.5 times slower than bzr.
    Without the result from bzr-1.6.1 it is 2.6 times slower (~43s vs 17s).
  5. Integrity checking: hg is by several orders of magnitude faster than bzr which just took too long - everyone stopped it after varying time (30s to 17 min), because the output spoke of hours remaining, one had an integrity error. hg needed about 1 min.
  6. Local clone: hg is 11 times faster (39s vs. 7.14 min).
    Without the 1m15 result from the high disk load host it is 16 times faster (26s).
  7. Local clone with hot filesystem: hg is 14.9 times faster (26s vs. 6.5 min).
  8. Hot copy of just .bzr / .hg: The speeds are about equal, so the difference doesn't come from raw filesystem speed (2s).
  9. Additional Bazaar tests to check shared repository cloning performance (you only get this when you use a shared repository and only clone that shared repository): With shared repository and hardlinks bzr only needs about 5 seconds for cloning.

Mercurial vs. Bazaar speedtest clone and log - update: hg 1.1 vs. bzr 1.10

I repeatet my test with the provided Python 2.x repos from the DVCS PEP for Python to check the performance of Bazaar and Mercurial.

All these tests are done only once with some mostly constant load, so they don't qualify as scientific tests, but they give a good impression of the differences between Bazaar (bzr) and Mercurial (hg).

- Bazaar 1.10
- Mercurial 1.1

This comparision should be fair since Bazaar 1.10 is more recent, but Mercurial 1.1 is a major release.

Mercurial vs. Bazaar speedtest clone and log (unscientific)

I just did a test with the provided Python 2.x repos from the DVCS PEP for Python to check the performance of Bazaar and Mercurial.

(this is a slightly changed version of a mail posted to the mercurial list: )

All these tests are done only once with some mostly constant load, so they don't qualitfy as scientific tests, but they give a good impressing of the differences between Bazaar (bzr) and Mercurial (hg).

- Bazaar 1.5
- Mercurial 1.0.2

These are the ones which are marked as stable in my Gentoo tree (amd64).


Vergleiche | Comparisions



Mercurial vs. GIT, Leistungstest für lokale Operationen

English: A speed test for Mercurial and git (in german). -> Links to other tests. Update: I wrote a new test for use in server applications, since they are the only place where a difference of 30-60ms really matters: hg vs. git for server applications.

Ich habe ein paar Testsskripte geschrieben, um die lokale Leistung von Mercurial und GIT vergleichen zu können.


Mercurial ist ein verteiltes Versionsverwaltungssystem.

Links zu Mercurial:

- Mercurial Webseite.

Webseiten einfacher aktualisieren mit Mercurial und lftp

-> Webseiten auf den FTP-Server laden wird einfach "hg push".

Ich schreibe seit langem eigene Webseiten, und die Notwendigkeit, sie jedesmal von Hand auf den Server hochzuladen, wenn ich etwas geändert hatte, war mir seit Jahren ein Dorn im Auge.

Vor kurzem habe ich nun angefangen, die Webseiten mit Mercurial als Versionsverwaltung zu bearbeiten, und Mercurial hat eine sehr praktische Funktion: Hooks (also Anker).

Damit kann ich einen Befehl ausführen, wenn ich in meiner Versionsverwaltung eine bestimmte Handlung ausführe.

Inhalt abgleichen
Willkommen im Weltenwald!

Beliebte Inhalte news

Kommunikation im Internet ist in Gefahr!

Liebe Besucher,
leider müssen wir euch kurz unterbrechen:

Das EU-Parlament stimmt nächste Woche über eine Urheberrechtsreform ab,
die alle kleinen Kommunikationsplattformen in ihrer Existenz bedroht.

Offener Brief der Forenbetreiber

Wir bitten euch daher darum, dass ihr

Vielen Dank für eure Unterstützung!

Euer Draketo

Wir sind Teil des #321EUOfflineDay