Use Github with Mercurial

A week or two ago I broke one of my git repositories. Because the solution cost me a lot of time, too many nerves and two commits, I have now returned to Mercurial. This tool may not be as powerful as Git, but the error messages and documentation are much easier to understand in my opinion.

However, I still want to use Github because of its widespread use. Be it to publish something there myself or to participate in third-party projects. Mercurial offers a plugin called hg-git for this purpose. With it, you can download a Git repository and it is automatically converted into a Mercurial repository locally. If you now make changes, they are then changed to be compatible with Git before being uploaded to a Git repository. Setting up hg-git is also quite simple.

For the following instructions, I assume that both Mercurial and python-dulwich are installed on the computer and that the directory Projects exists in the home directory. Of course, you can give the directory a different name.

First, change to the Projects directory in the terminal emulator of your choice and download the hg-git files there.

cd ~/Projects
hg clone hg-git

Alternatively, you can install hg-git via the package management of your distribution.

Next, add the following content to the .hgrc file in the home directory. If the file does not yet exist, simply create it and enter the three lines.

hgext.bookmarks =
hggit = ~/Projects/hg-git/hggit

Line two activates the plugin Bookmarks, which in this case simulates branches. Line three activates the hg-git plugin that we just downloaded.

In the Projects directory, we now download a Git repository with the following command (please adapt the Github address and the target directory fryboyter.git to your own circumstances).

hg clone fryboyter.hg

Because this converts from Git to Merurial, it may take some time depending on the size of the repository.

Next, change to the directory in which the Mercurial repository now created is located. In this example, this is fryboyter.hg. Finally, execute the command hg bookmark -f main there. Instead of main, you must enter the name of the main branch. Otherwise Mercurial will not recognise any changes during a push.

Now everything should work. In my tests, I was able to pull from Github and push to Github without any problems. That’s all I really need in my case. What I noticed during the whole process is that the local Mercurial repository is less than 30 MB in size. The local Git repository, on the other hand, takes up a bit more than 60 MB of space. That’s not the end of the world, but it’s still an interesting detail.

OSBN | General

VSCode - Create snippet for Front Matter

I create my articles using Markdown files. At the beginning of this file is the so-called front matter area where information such as the title, the date of publication or the tags of an article are entered.

Creating this area manually every time is annoying in the long run. Hugo, the static website generator I use, offers templates for this purpose, so you can create a new article with a command like hugo new

However, I prefer to do everything with the editor. Currently I use VSCode. This editor offers so-called snippets with which you can create templates.

To do this, select “User snippets” under preferences in the “File” menu. In the drop-down menu that now appears, select “New global code snippet file…” and give the snippet file a meaningful file name.

Fill the file that now appears with the following content.

  "Blog post frontmatter": {
    "prefix": "fmc",
    "description": "Creates frontmatter for Hugo articles",
    "body": [
      "title: ${1}",
	  "- ${3}", 
    "- ${4}",
    "slug: ${5}",

In the first line you enter the name of the snippet that is displayed in the editor. The prefix serves as a shortcode with which you can quickly insert the content of the snippet. You can also enter something else here. I have chosen fmc (front matter create).

The content of the snippet that is to be inserted automatically is created in the body. In my case, the front matter area is started with ---. This is followed by the title, the date, the categories, the tags and the slug through which the article can be reached. The front matter area is ended again with ---.

Finally, save the file. If you now create a new article, enter fmc in the file. This should cause a menu to appear in which you can execute the snippet. If you do this, the following content should be entered automatically.

date: 2021-01-02T13:01:02+0100

In the code example above, some of you will have noticed ${1}, ${2} etc. These are jump marks.These are jump marks. Once you have inserted the snippet using fmc, you can use the tab key to jump to these places one after the other and thus fill in the relevant fields.

OSBN | General

Update to Wallabag 2.4.0 - Row size to large

Wallabag is a self-hosting tool that allows you to save interesting web pages for later reading. A few days ago version 2.4.0 was released to which I wanted to update my instance.

Unfortunately the update aborted with the (abbreviated) error message “Syntax error or access violation: 1118 Row size too large.” and the installation was no longer usable.

The reason is that at least one table in the Wallabag database has the row format “REDUNDANT” or “COMPACT”. You can display the affected tables with the following database query.

FROM information_schema.TABLES 
WHERE ENGINE = 'InnoDB' AND ROW_FORMAT IN('Redundant', 'Compact') 

As the output was limited to only a few tables and I don’t want to do a more complex solution, I changed the row format manually to “DYNAMIC” with the following command.


Instead of $TABLENAME, enter one of the tables that were displayed with the database query.

Once you have changed the relevant tables accordingly, the update should complete without errors and the relevant Wallabag instance should be usable afterwards.

OSBN | General

Hugo - Remove content from sitemap

Google Search Console has complained that two links on my site are blocked by robots.txt even though they appear in the sitemap. How do I get them from the sitemap that Hugo creates automatically?

The solution is actually quite simple. First edit the related articles and add sitemap_exclude: true to the metadata.

title: Secret Article
date: 2019-06-11T19:12:45+0200
sitemap_exclude: true
slug: secret-article

Now it is necessary to adapt the template with which the sitemap is created. Therefore create the file sitemap.xml in the theme directory under layouts/_default and fill it with the following content.

{{ printf "<?xml version=\"1.0\" encoding=\"utf-8\" standalone=\"yes\" ?>" | safeHTML }}
<urlset xmlns=""
  {{ range .Data.Pages }}
    <loc>{{ .Permalink }}</loc>{{ if not .Lastmod.IsZero }}
    <lastmod>{{ safeHTML ( .Lastmod.Format "2006-01-02T15:04:05-07:00" ) }}</lastmod>{{ end }}{{ with .Sitemap.ChangeFreq }}
    <changefreq>{{ . }}</changefreq>{{ end }}{{ if ge .Sitemap.Priority 0.0 }}
    <priority>{{ .Sitemap.Priority }}</priority>{{ end }}{{ if .IsTranslated }}{{ range .Translations }}
                hreflang="{{ .Lang }}"
                href="{{ .Permalink }}"
                />{{ end }}
                hreflang="{{ .Lang }}"
                href="{{ .Permalink }}"
                />{{ end }}
  {{ end }}

This corresponds initially to the standard template for the sitemap. Now change line 4 as follows.

{{ range .Data.Pages }}{{ if ne .Params.sitemap_exclude true }}

Finally add another {{ end }} to line 21.

{{ end }}{{ end }}

If the page is rebuilt now, all contents where sitemap_exclude: true is specified should no longer appear in the sitemap.

General | OSBN

Some articles are now offered in multiple languages

In the last few years I have been thinking about publishing at least some articles in English from time to time. So far, however, the technical implementation was too cumbersome for me. But with Hugo it’s done pretty easy, as I noticed today.

The first thing to do is to add the following entries to the configuration file config.toml.

DefaultContentLanguage = "de"

        languageName = "Deutsche Version"
        weight = 1
        languageName = "English version"
        weight = 2

The first line specifies that de is the default language. The rest defines the existing languages, gives them a name and a weighting (the lower the more important).

Now we create a new article. Let’s just call the file Let’s assume that the article is important enough to be published in English as well. So we create another article and name the file As you can see the title has been extended by a .en. Hugo now automatically understands that the article with .en is the English version and the other one is the German version.

But what if someone opens the German version but doesn’t understand German? There should be a kind of switch available. For this one can use for example the following code.

{{ if .IsTranslated }}
	{{ range .Translations }} | {{ .Language.LanguageName }} {{ end}}
{{ end }}

This checks whether the article is also available in another language. If so, a link to the corresponding versions will be shown. If not, nothing is displayed. I put this code on under the main heading of all articles. If the link “English version” appears at an article, I wrote the article in English as well. Currently one will find this link only at this article for the moment. Gradually there will be more articles in German and English (also older ones) available.

OSBN | General