Paul Hammant's Blog: Git becomes version-control's lingua franca wire protocol

Subversion was kind of it for a few years - a sturdy wire protocol that Git and Mercurial could be push/pull to for introp outside their ecosystem.

It is increasingly becoming Git now. Major tools vendors mast have Git in their “is compatible with” list. More esoteric things like SparkleShare push Git to a place outside of source-control, as does VersionRocket. Aiming at one wire-protocol makes things easy for those seeking allow choices, and those will come too.

Two commercial SCM makers now speak Git on the wire, to their industrial strength back-ends: Perforce and PlasticSCM. They have a video for a forthcoming server release speaking Git to Atlassian’s SourceTree client (soundless), but no documentation as yet.

Perforce has had Git-Fusion for a while - it’s a bridge that allows Git clients to push/pull to a traditional Perforce server. What’s new this year is their GitSwarm, that makes a portal experience around a Git front end to Perforce’s back-end.

Other tech’s depending on Git

Increasingly package maintainers are targeting Git as the mechanism by which packages are maintained for platforms. That’s OS X’s Homebrew (which has sidelined Macports - Subversion and Fink - CVS). It is now also Arch Linux’s AUR package manager and Gentoo’s package manger too (both in the last 48 hours).

Config-as-Code the Consul way, can be glued to Git as a backend via git2consul.

Granted those are more normal usages of Git for sourccode managememt, but there are also non-mainstream usages of Git. For example, there are a dozen Git-backed wikis now Realms, Gitit, ikiwiki, Gollum, zim-wiki, Ewiki, Wi-wiki, G-wiki, Waliki, Melkor, Smeagol, Wigit. Who doesn’t want to escape lock-in for extensive sets of wiki pages?

A moving target

Git is a fast moving target though, whereas Subversion was very slowly moving.

There are some things that I think Git needs to do in future releases, though:

• sparse-clones - it already has sparse checkouts.

• go beyond the 1GB “safe clone size” limit.

• have an ACL/permissions design for branches, and subdirectories.

• better handling of items that are already zipped

• sub-directory cloning (a derivation of sparse-clones, I guess)