bzr git-serve

What is it?

All cool git features happen locally, and the server is only involved for cloning, pulling and pushing. So really, just pulling and pushing. The Git objects and wire protocol are stable and straightforward so we can allow people to push and pull from a Bazaar repository with a Git client.

Overview

Like the rest of bzr-git, the git-serve functionality uses dulwich to communicate with Git clients and to produce and parse Git packs. It also shares the code for converting between Git and Bazaar objects with other operations in bzr-git. All this means that not much specific code is needed to provide Git hosting on top of Bazaar repositories.

A bzr command, 'git-serve', is used to replace git-daemon for accessing using git://. Drop in replacements for git-upload-pack and git-receive-pack are also provided for providing git+ssh:// access.

FAQ

Why don't you just use Git? There is no universal client for revision control that all users are happy with. By providing a common server and allowing developers to use whatever client they want then more developers can be satisfied.

Why don't you add bzr-serve to Git? Bazaar has an API that makes git-serve easy. The Git model can be treated as a subset of Bazaar, the inverse is not true.

What happens when a new version of git with a new feature, incompatible with git-serve, is released? As already mentioned, most features are *entirely local* so its very unlikely that a new release of Git will require changes to git-serve. Of course, if the protocol changes, we will update git-serve. As the protocol will only be extended in a backward compatible manner (using the capabilities system), changes to git won't break peoples ability to clone, pull and push which are the only features that the protocol is there to support. If a new Git client can't work with git-serve, it won't work with current generation Git servers either.

Max Kanat-Alexander adds, "The first thing to understand is that the git server protocol is very simple. When I was writing VCI, I talked to the git developers and asked if they were going to add any more features to the server. They said no, it's only supposed to allow you to clone from it, and that adding any other features would increase the attack surface (a particularly valid concern when writing servers in C).

Won't it lag behind the real thing? It's small and relatively straightforward. Any small changes will be easy to add in, and anything that breaks git-serve would break communication between real git servers and clients.

Won't you end up only able to use the intersection of the features of the two version control systems? Git does not do any actual operations over the wire, it does all of its operations on your local repository, so you wouldn't lose any functionality. To extend on that further, all of Gits functionality is built on top of 4 objects (a commit, a tree, a tag and a blob) with refs pointing into these structures. git-serve only has to care about storing these fundamental types, and everything else just works on top of this. The Git and Bzr repository formats are similar enough that all Git repository information can be stored in Bzr without any losses.

The Bzr repository information is somewhat more complete than git, which is the simpler system. There isn't anything on the horizon to indicate that git will be vastly increasing its range of repository data any time soon.

Won't the bridge will have to be updated whenever either the bzr or git formats change? The bzrlib API means we can support any shipping Bazaar formats. Despite the reputation for Bazaar releasing new formats, old ones are still supported. The Git protocol has a capabilities mechanism which will shield users from Git changes. Obviously any enhancements to the Git protocol will be quickly supported as they make dulwich and bzr-git faster too.

This is an abstraction, and abstractions are always leaky. There is no way a git compatibility layer on top of a bzr repository will ever be as good as a native solution, just like git-on-svn isn’t as good as a pure git solution. The free desktop is full of abstractions, and yes they do introduce problems. git-svn is especially bad because of the gap between the structure of the 2 systems. They are quite different. If you look at the objects in Bazaar, you will see a revision object (which can have multiple parents), an inventory of data (list of files and directories), and a series of blobs of data. In Git you will see a commit object (which can have multiple parents), an inventory of data, and a series of blobs of data.

What happens when (not if, when) the git protocol changes in an incompatible way? Will we be at the mercy of someone to hack and fix the compatibility layer? Will the original author still be around and interested enough to do it, possibly years down the road? It's really unlikely that Git will stop working with all current servers. But in the unlikely chance that it does, you will have your projects history in Bazaar and Git formats. You are not tied to the compatibility bridge.

Isn't bzr is still slow for network operations? Bazaar's network code isn't needed to support the Git wire protocols, so this is irrelevant.

I heard this project has a bus factor of 1? There are several developers.