You can do the same setup with Git, either by having separate clones, perhaps with shared object database (alternates or symlink), or by using multiple working directories with single repository (with which contrib/worktree/git-new-worktree would help). Nevertheless the multiple branches in single repository, with switching between branches using single working area, was something user’s *wanted* and was created at user’s request, and found very useful.

* Semantic revision IDs::

Numerical monotonic (well, partially ordered in the case of nonlinear history) revision identifiers are possible only if there is *central numbering authority*. Which means it is possible only in centralized workflow. Or they are local and cannot be used to communicate with other developers.

Besides I don’t think that e.g. ‘r16437′ is easier to use than ’3f5907d’ shortened SHA-1 identifier, or more commonly used ‘HEAD^’, ‘master~2′, ‘v1.2.3-rc1′, or ‘v1.6.4.2-260-g3f5907d’, or ‘@{1}’. Also if you have ‘r15467′ and ‘r15476′ you only know the topological relation between them *if they are on the same branch* (if one is ancestor of the other).

* Hierarchical history::

Here I don’t understand what you are talking about writing “With git, all your history is flat.” Take a look at output of “gitk” or “git log –graph” / “git log –graph –oneline”. If you are talking about merge messages, there is always `merge.summary` configuration option, where merge commit contains shortlog(s) of merged branch(es).

* Serving a branch is uncomplicated::

You can serve Git repository via HTTP with any web server with a little bit of extra information generated by git-update-server-info, usually run from hooks. Also you have Gitosis third-party tool for easy setting up SSH access. But I agree that it could be easier.

As to popularity of GitHub: isn’t Launchpad as popular among bzr users?

* Plugins and Aliases::

Plugins, stable API, and ever changing repository format (for Bazaar) versus scriptability (suing low level “plumbing” tools provided for that purpose) and stable repository format allowing for independent reimplementations like JGit or Dulwich are design decision. *Both* have their advantages and disadvantages.

Git has also aliases, with the limitation (needed for scriptability) that you can have the same name of alias as existing Git command. Many commands have configuration which are equivalent to command line options, but the idea to add ability to specify default command line options was discussed but didn’t made it into git (because of difficulties with not breaking existing scripts).

* Library Interfaces::

“The main interface of git is the command line interface. It is used both for user interaction and automation [...]“. Not true. Well, not entirely true. There is set of git commands (so called “plumbing” commands) which are meant to be used for automation (commands like git-checkout-index, git-update-index, git-diff-files, git-write-tree, git-cat-file, git-symbolic-ref), and there is set of git commands (so called “porcelain” commands) which are meant to be used for user interaction (commands like “git show”, “git log”, “git diff”, “git branch”).

There is currenly no Git library (the work on libgit2 is stalled), but on the other hand stable repository format and transmission protocols (with place for extending it) allow for *reimplementations* of Git in other languages (JGit in Java, Dulwich in Python, Git# / Managed Git in C#) even if there are no libified bindings for other languages.

I agree that it would be nice to have Git library.

* Gun safety::

“With git I got several times to the point where I just deleted the repository to start over. [...] Maybe I am just not experienced enough with git.”

Yes, you are not experienced enough with git.

In the case of botched merge, you can always do “git reset –hard ORIG_HEAD” to go back to situation before merge. Also, if you don’t want to commit merge automatically, there is `–no-commit` option…

* Conclusion::

If bzr just works for you, there is no reason to swicth to git.