Git Becomes Version Control's Lingua Franca Wire Protocol

DZone 's Guide to

Git Becomes Version Control's Lingua Franca Wire Protocol

A summary of the rise of Git as a popular source control standard.

· DevOps Zone ·
Free Resource

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

It is increasingly becoming Git now. Major tool vendors must 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 of 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 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 RealmsGititikiwikiGollumzim-wikiEwikiWi-wikiG-wikiWalikiMelkorSmeagolWigit. 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 slow-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)
agile, devops, git, scm, source control

Published at DZone with permission of Paul Hammant , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}