Teaching Git in SH: a summary
Carl reports about his week-long Git teaching in China, and the various thoughts he had along the way.
While here in China, I’ve been thinking of traffic.
Compared to Sweden, there’s a proliferation of vehicle types. In Sweden you’d see cars, trucks, and bikes on the road. Here you see that and more: mopeds of different sizes, bikes and motorcycles with flatbeds on them, mopeds that pretend they are cars, cars that look like half a car, and various hybrid types between these. It’s as if China has already experienced the traffic equivalent of polyglot persistence.
Not only that, but everyone seems to get by with lots fewer traffic rules. That’s my impression at least, as a safety-minded Swede. Pedestrians crossing the street everywhere, dodging in front of or between cars. Bikes and mopeds going against traffic. Oh, and apparently one of the few traffic rules here says that you’re free to turn right any time, regardless of what the lights say.
But the amazing this is, it works. There are very few accidents. I haven’t seen one, at least. The whole system seems to work through honking. Whereas in Sweden, a car honk would mean something very much like “Pay attention, you’re doing something quite wrong!”, in China it means something much more like “Oh hey, I’m here! Hi! Got space for me in this jam?”
A Git conflict is a bit like a traffic jam: two developers wanted to occupy the same piece of source code at the same time, and now they’re honking at each other, waiting for a solution to present itself. In traditional (centralized) version control systems, the tendency has been to introduce traffic lights everywhere, to make it clear who gets to modify the source code, and who has to wait. It’s a sensible model, and it certainly has safety to speak for it.
But Git (among other contemporary distributed systems) offers an interesting alternative: let’s ditch the traffic lights, and just handle conflicts as they occur. Does your change conflict with someone else’s? Well, then it’s your mess to clear up, go right ahead and write yourself out of that tangle. If you’re of the old centralized school, or a Swede, this sounds like madness at first — who in their right mind would want to give up the safety conferred by traffic lights in favor of… anarchy?
But it does work, and there are even some hidden advantages. In the literature, the traditional model of providing traffic lights everywhere is called pessimistic concurrency, whereas Git’s laissez-faire model is called optimistic concurrency. Interestingly enough, processor manufacturers and developers of concurrent algorithms face the exact same choice, between pessimistic and optimistic concurrency. And their conclusion is largely the same: optimistic concurrency scales better.
Basically, the old centralized version control systems give you safety whether you need it or not, at the cost of slowing everything down a little. The new distributed systems have an attitude of “OK, there will be conflicts on the way, but we’ll handle them when we get to them”. Since usually there aren’t conflicts, normal work progresses faster, with fewer distractions. Most cars meeting on the road do not head straight for each other and start honking.
All of this makes for a cute analogy, I guess, and it was something that struck me at the beginning of the teaching week in Shanghai. I even told the first group about it. If someone else had made the comparison, I would probably have nodded and said “yeah, sounds about right”.
The teaching week itself went fine. There’s something about Chinese audiences that makes them a little extra rewarding to teach to. I think they simply pay a lot of attention. Any teacher will tell you that that in itself makes a big difference.
Besides which, the questions were interesting, and showed that people were following along.
On the Friday, we had a Q&A session for people who were interested enough to come ask Git questions outside of the curriculum. Now, it turns out that when you arrange such a session, the people who turn up tend to be the people who are not based in Shanghai — likely because they are away from their daily work anyway, and don’t have competing priorities. But we were a cozy gang of about ten people, and filled a morning of discussion about the different bits of Git.
After doing Git for a week like this, I experienced another insight, one I hadn’t had before. Git (and distributed version control) mirrors the way the Internet works. The Web is a big tangle of servers and clients, all talking to each other without any central authority. Peer-to-peer services like Bittorrent have disrupted the way we think about content distribution. Cryptocurrencies like Bitcoin are beginning to do the same thing with money. Git belongs in this bucket of fast-moving, fluent, net-enabled technologies.
…weirdly enough, since one of the big selling points of distributed systems is that you don’t need a network connection.
Git is the technological enabler of meritocracy within a project. In a real meritocracy, it doesn’t matter who you are, only what your contributions are. I just accepted a contribution in a Git project from a person I’ve never met and whose name I can’t recall. I chose to accept the contribution because the content looked good. In Git, the one who pens the contribution is called the author and the one who accepts it into a project is called the committer. Before I had started using Git, it hadn’t even occurred to me that author and committer could be different roles. Every time the author and committer are different people, a contribution happens to a project that likely wouldn’t have happened before.
Git encourages this kind of distributed collaboration. It does it very well. The whole branching model is geared towards giving everyone equal status. By default, there’s no privileged central repository, there’s no privileged developer, and no-one tells you which workflows you have to pick. (The last point is kind of disorienting for people who come from one of the old systems, where there’s usually One True Way to do things. Entering into the world of Git where there’s lots of possibilities tends to lead to a feeling of vertigo.)
Perhaps the best example of this kind of meritocracy is Github. Github doesn’t really add much new on top of Git, it just exposes it in ways that tend make people contribute to each others’ projects. Whereas on Facebook you “like” people’s posts, and on Twitter you “retweet” them, on Github you “fork” someone else’s project, make a contribution, and then ask them to reintegrate it into theirs. Again, I don’t really think of Github as something more than Git. They did a remarkably good job of creating a web interface for the things you normally want to do with Git, and adding wikis and issues and web pages around each project… but in the end, what they are doing is harnessing Git’s powers, not extending them.
All this explains to me a bit better why I like Git so much, and why I want to invest time in learning it well. Because Git is essentially version control’s reply to the Internet. It’s the way we should be working if we’re aware that the net is becoming more and more of a natural part of our lives.
Even on this social level, what we’re harnessing is a kind of anarchy. The occasional motto in an early open-source project I was a part of was “Trust the anarchy”. In other words, lots of chaotic contributions will mix together, and if we just do some minimal guidance, then the sum of all those contributions will be greater than each individual one. In this sense, Git inherently trusts the anarchy.
What’s next for Edument and Git? We’re going to be doing a deep dive into our Elite Git course, for people who want to implement Git workflows inside an organization.
Entry filed under: Uncategorized.