Plugins in Version Control

What is up with these version control systems that use plugins to do everything? I understand that having an extensible system is very useful if users want to create something custom. Mercurial and Bazaar both support plugins written in Python, while Git has an extensive set of commands that allow you to easily write custom scripts in any language.

However, being able to extend a program is not an excuse to ship a product missing features. One of the things that makes Git powerful is that it ships with a lot of capabilities built in.

Take Bazaar for example. If you want to commit only part of the changes in a file, you need the BzrTools extension. To rebase revisions you need the Rebase extension. You need extensions to show diffs in colour, to push all branches at once, and even to remove untracked files in your working tree! Why aren’t these included by default? Are they afraid a user might be afraid to see a coloured diff? Or is it too much work to support these tools directly?

This exactly the problem with plugins: it separates the functionality from the main program. Who is going to install some weird plugin on some website to gain functionality? Who created the plugin anyway, can it be trusted as much as the program itself? How is it updated? What if there’s an incompatibility between the plugin version and the program version? What if I’m using some feature, but others that I’m working with can’t do the same, because they don’t have the plugin installed yet?

Having an extensive set of tools shipped by the program isn’t a bad thing, it’s good. It allows you to use the same workflow and suggest the same solutions to everybody else, without requiring a certain plugin. It also makes features easier to use, as you don’t have to manually install something first.

Git is easily capable of supporting its full feature set release after release, and keeps adding useful features. When upgrading, you can be sure that all your previous commands are still usable. As they are integrated into the system, you can be sure that they get the same amount of attention as anything else.

This last point is more important than you might think. After all, you’re talking about your source code here. You want the program that you use to be reliable, to work consistently across releases. You don’t want to depend on something that you don’t fully trust.

Relying on plugins is just a way for lazy programmers to maintain less code. I really prefer Git’s builtin tools more than some lousy plugin that doesn’t even have it’s own website. If you stick to only core functionality, at least be the fastest ;).

On mainline merges and fast forwards

Bazaar has a somewhat different notion of merging in the case of no new commits than Git and Mercurial do. The reason for this is the notion of a “mainline” in Bazaar. This supposed mainline is meant as a silver line through your history. All commits should be merged into this mainline, giving you a nice overview of development. Bazaar has even integrated this into their “log” tool: commits that have been merged “into the mainline” are indented to show this.

Git and Mercurial use another approach, based on the fast-forward method: If there are no new commits on your branch, but there are new ones on the remote, Git and Mercurial just fast-forward you to that commit. No merging or so, your new HEAD will just be the same revision as the remote.

The reason they do this is because Bazaar’s approach does come with some problems. The first and most obvious of this is performance. The “bzr log” command is really slow as it reconstructs history every time, figuring out what the mainline actually is and then showing the history in a neat way. This scales badly: For Cairo, with 4000 commits, “bzr log -l10” takes just over a second to display the first 10 log messages. Mozilla-central, with 15000 commits, already takes 5 seconds. Samba with 24000 commits takes 10 seconds to display the first few log messages, which I would call unacceptable. It gets even worse when you try the Emacs repository.

However, that is not the biggest problem. The problem with explicit merges is the pollution of your branches. The outlining Bazaar makes is only useful if it is “correct” and does not show pollution. This can be a real trouble when two developers work together on a single feature, and merge with each other.

An example

Let’s say that we have a single upstream with some commits. There are two people working on something, one in the branch1 branch and the other in the branch2 branch. Both do a commit on their own branch, then branch1 decides to merge with branch2. After this, branch2 merges with branch1, to get their features.

What this means is that after both have merged, they should have the same tree (given that the merge was conflict-free). One might therefore also assume that they have the same branch history. This is not true however.

Show branch1 log

Show branch2 log

Who is right here? Should the “Add b” commit be indented or the “Add c” commit? As you can see, the notion of “mainline” is then local to a developer, beating the whole point of having a “global line through history”.

It gets even worse. Suppose branch1 merges the changes from branch2 again (just to make sure he has everything) and pushes it to upstream. Then branch2 updates from upstream in order to continue working. The final output of his log looks like this:

--------------------------------------------
revno: 4
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: branch2
timestamp: Tue 2008-06-03 16:25:55 +0200
message:
  Merge with upstream
    --------------------------------------------
    revno: 1.1.3
    committer: Pieter de Bie <pdebie@ai.rug.nl>
    branch nick: branch1
    timestamp: Tue 2008-06-03 16:25:52 +0200
    message:
      Merge with branch2
--------------------------------------------
revno: 3
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: branch2
timestamp: Tue 2008-06-03 16:25:51 +0200
message:
  Merge with branch1
    --------------------------------------------
    revno: 1.1.2
    committer: Pieter de Bie <pdebie@ai.rug.nl>
    branch nick: branch1
    timestamp: Tue 2008-06-03 16:25:49 +0200
    message:
      Merge with branch2
    --------------------------------------------
    revno: 1.1.1
    committer: Pieter de Bie <pdebie@ai.rug.nl>
    branch nick: branch1
    timestamp: Tue 2008-06-03 16:25:45 +0200
    message:
      Add b
--------------------------------------------
revno: 2
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: branch2
timestamp: Tue 2008-06-03 16:25:47 +0200
message:
  Add c
--------------------------------------------
revno: 1
committer: Pieter de Bie <pdebie@ai.rug.nl>
branch nick: upstream
timestamp: Tue 2008-06-03 16:25:42 +0200
message:
  Base commit

Does that look readable to you? This does not show a nice overview of what has happened during the development of a feature. Instead, it is littered with merges. This kind of noise may make developers wary of merging, which is not good.

Compare this to how Git and Mercurial handle this. Even after the to- and fro merging, the log still shows only four commits:

commit 78cd0c44cd93800a169617a72832bcb6a984f9a3
Merge: 598b3f8... ecc0685...
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:27 2008 +0200

    Merge comparison/temp-dir-2/branch2

    * comparison/temp-dir-2/branch2:
      Add c

commit 598b3f859ff9f69733a2ddd1406229cd3c203591
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:26 2008 +0200

    Add b

commit ecc06852b9f76cdcf9285f6eac7c39c002e566e7
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:26 2008 +0200

    Add c

commit 5828b28ff1fc41c674cabe9b839621a72f3effa5
Author: Pieter de Bie <pdebie@ai.rug.nl>
Date:   Tue Jun 3 17:04:26 2008 +0200

    Base commit

Implications

The important point of this is that in the way Git and Mercurial work, it doesn’t matter who does the merge. Their workflow encourages the use of forking, giving more freedom to the developers to do what they want and merge with whom they want. The Bazaar approach, in contrast, discourages merging by anyone else than those in control of the mainline, as otherwise the history will look ugly and unreadable: the first branch is somehow “special” and must be maintained that way. In a distributed VCS, it should not matter who does the merge. By making sure that the maintainers have to merge from you, you get less freedom in deciding how to do your development.

While the outline may seem nice, sometimes having it is just plainly wrong. If I want to update my branch to the latest upstream, I want to be equal to the latest upstream, not to make it a merge. Also as we just saw with cross-developer merging, there sometimes is no way to determine who is “the mainline”. Making a simple branch something that it isn’t is only bound to spread confusion among the users.

See also this reply by Linus Torvalds that basically says the same thing. Also take a look at the rest of that thread if you’re interested.

On History Rewriting

This is just a short note on history rewriting.

During my conversion process, I made some significant changes to the bzr-fast-export tool, as it can’t export some repositories by default. As I was hacking away quickly, I made some fast bzr commits, so that I could make nice patches out of them later on.

Today I wanted to do just that, but it appears to be impossible to rewrite your history with Bazaar. I would like to merge some commits, reorder them, change the log message and split one commit up in two parts. Also, I’ll have to adjust the author info, as I didn’t set it up correctly before.

Not too difficult, you’d think. However, I can’t figure out how to do it. The best thing I’ve found is bzr uncommit, which will return you to a previous state. In order to work with this, I’ll have to export a diff for every commit I did, then revert to the parent commit, apply a patch, and commit it again. If I want to split up a commit, I’ll either have to install and use the shelve plugin , or split up the patches myself.

Compare this to Git’s excellent rebase —interactive script. It will allow you to do everything I just mentioned, and then some. This has obvious advantages: you don’t have to worry about your patch series until you’re done with it. Some changes might not be obvious from the start, and being able to edit a log message to make it more clear as valuable tool. With Bazaar, once you’ve committed, you’re pretty much committed to it (pun intended). You’ll have to think ahead of time what you’re going to commit, in what order, and with what message. Obviously I prefer the freedom of Git in this case.

Import tools

The last few days I have spent some time using the different import tools that exist. Basically there are two ways to convert a repository: by using some tool-native tool, or by using the fast-{import,export} tools.

A bit of history.

Somewhere in 2006, Git introduced the git fast-import tool. It was created to allow fast importing of tarballs and to allow other revision systems to export their data easily and fast to Git.

Examples of front-ends are cvs2svn and hg-fast-export.py, which allow exporting CVS and Mercurial repositories to Git.

In the mean time, more importers and exporters have been created. For example, Bazaar has both a bzr fastimport plugin and an export script. Git has also implemented a git-fast-export, which should allow you to export your Git repository to any of the importers. Mercurial does not have a fast-import variant yet.

The reality

The reality, however, is that it is very difficult to make these tools work together. Git’s fast-import tool seems the most robust and is willing to take in anything well-formed. There was a bug in the fast-export tool when having a commit with multiple parents, but this has been fixed since.

The hg-fast-export tool also seems to work fairly well. It exports all branches it has, and is not likely to crash. It has succesfully exported all the repositories I gave it.

Bazaar’s tools seem to have the most problem. The fast-import front-end will crash on invalid encodings and other peculiarities that Git’s tool seems to have no problem with. The fast-export tool has several problems which I tried to fix. One of these is handling ghost commits, which is a somewhat bizarre feature of Bazaar where you can say a commit was a merge without supplying one of its parents. When Bazaar has recursive renames (for example, renaming “a/” to “b/” and “a/a” to “b/c”) it will provide output that is invalid for git-import. I also get a different number of revisions after the import is complete. I’m not sure yet what’s going on there. Furthermore, Bazaar’s tool might as well be called slow-import, as it can take a day to import a somewhat large repository.

The same was true when importing the Emacs repository; I couldn’t find any way to convert it into a Git repository. Currently I’m using the Emacs repository on repo.or.cz, but that one differs in history from the Bazaar one.

HG-convert

As Mercurial does not have a fast-import tool, I have to use the “hg convert” command/plugin to import repositories in Mercurial. This tool seems to crash every so often, especially if you provide it with a non-standard Git repository, like git.git or the linux kernel. I’m also not sure if it handles branches correctly; sometimes it seems to import them, and sometimes it seems to just ignore them. As Mercurial has no way to import Bazaar repositories, I had to import the Git versions of them. This means that most conversions have a different number of commits in all three versions.

The branching problem

All three systems have a different way to handle branches. With Git, branches are just references to specific commits that are kept totally out of the repository history. Mercurial has a file within the repository called .hgbranches that names the branches and which allows you to see the history of the branches. Bazaar seems to have the most bizarre way of keeping branches. They use the old and confusing concept of SVN’s “branches are directories”. Especially when importing this can be a bit difficult. The bzr fast-import tool allows you to import multiple branches, and they will be created as different directories. I’m not sure yet how to handle this. Is there a way to get the total number of revisions of all branches? What happens if I delete a branch, can I get it back easily? Will space be freed in the repository after deleting the branch? Can I switch between branches easily, or do I need to keep these working trees checked out?

All this vagueness and general incompatibility make me think about dropping branch support in my conversions and only work on a head branch. I’ll still do benchmarks on branching and merging speed, but just don’t import all the branches.