git is for everyone

Linus Torvalds has changed the world twice now, dangit, which is 0 (±2 due to rounding errors) more times than I have changed it. His first world-changing contribution was of course, Linux, and his second was git. Linux is Torvalds’ My Antonia— widely regarded as his most significant contribution to the world. That means git must be his Death comes for the Archbishop. See the parallel I’m drawing here? I could have sworn I’ve mentioned this in a previous post. The former is widely regarded as his masterpiece, but the latter is the real magnum opus— it’s the one I would tell friends to read.

Many years ago, my wife came home and found me sitting alone in the dark with tears in my eyes: I had just finished the last episode of Battlestar Galactica (and it was lovely). Have I mixed enough metaphors here? The final episode of BSG is Willa Cather’s Death Comes for the Archbishop is Torvalds’ git.

However, while git may be incredible software, the underlying ideas are the real Edward James Olmos star.

What git is actually about

Git is not brilliant because it’s written in C and was able to host merges of the Linux kernel in less than a few weeks. It is not brilliant because it led to GitHub and arguably the mass adoption of open-source software as a business strategy. Git is brilliant because it’s a codified workflow for idea experimentation and reconciliation.

To \t or not to \t.


I’m not going to argue about which workflow is best: OneFlow, GitFlow, GitHub Flow, Forking Workflow, GitLab Flow, etc. Line endings, tabs v spaces, trailing commas– I’ll die on a lot of hills but you will not find me on the summit that is git workflows. The fact is, the power of git is found in its ability to support many workflows, extremely quickly, with extraordinary consistency, in a decentralized way.

Here’s the real meaty center of this post: git has transformed collaborative software development but the core ideas have a chance to transform so many other endeavors.


WordPerfect 5.1 |

Consider a word processor, like Google Docs. You can create a document and multiple people can edit the document at once. Google Docs is amazing, but only if you’ve never used any programming tools. Google Docs is slow and it’s unsafe. There is no quick method to start off on a new idea, a wild tangent, with the complete assurance that you can go back to an earlier state of the document. You can’t store side by side ideas and come back to them later– you can’t even look at ideas side by side. There is an awful linear history that is difficult to access, provides no good mechanisms for viewing differences, and doesn’t allow you to decide what constitutes a “revision”. There is no way to reconcile differences between drafts. There are only workarounds: creating copies, copy/pasting crap into other documents, making your own backups by hand. There is no way to work offline. There is no option but to trust Google with your data. What a terrible, horrible, no good, very bad workflow. Imagine what an impact decent tools could have for a writer.

I am related to two pastors (my father and one brother). They each write a twenty-five minute speech (long sermons are called “gravy-burners”) every week and the best tool they have at their disposal is the smoking, decomposing pile of refuse we call the modern word processor. They have no way to quickly experiment. No way to review progress or compare their own ideas.

Man that beat looks fatty.

Consider Pro Tools. This tool allows musicians to record tracks, arrange music, make the fattiest of beats, and the illest of rhymes. Realtime audio plugins are a modern marvel. But what’s this? — The only thing between the musician and utter destruction is an undo stack, a complete mastery of Save As, and decent knowledge of external backups. What happens when a musician wants to collaborate? Many musicians stick their projects in Dropbox, which is in itself a terrible, awful service that could use some distributed-version-control love. How do you try something quickly, or head a different direction easily, or foster collaboration without hitting the friction of your tooling not supporting the differences in your ideas? Git doesn’t directly solve these problems (though I have a strong suspicion that it could)– remember, git isn’t the point here, the ideas behind git are. What does an audio diff look like? How do you resolve conflicts between the aforementioned fatty beats? The idea of safe, distributed branching, comparing, and reconciling could have an incredible impact here.

Finally, consider the digital artist, working in 3d sculpting tools or Photoshop. Game artists may know about “version control” but the vast majority don’t use it. Even among the VCS-aware, there are no tools for diffing and resolving PSDs. What would those tools even look like? Why has Adobe not spent any time on letting artists easily try TWO things out at once, safely? Or collaborate on and reconcile different ideas?

I’ve run out of examples

I have not run out of examples like the pesky paragraph header indicates, in case you’re wondering. Ever done a thing and then wanted to try a new thing without compromising your ability to go back to that first thing? Ever wanted multiple people to work on different pieces of a thing and then safely reconcile their thing work? HAVE YOU EVER WORKED ON A NON-TRIVIAL THING???

If you answered yes to any of these questions, then git’s core ideas could help what you’re doing. We should be thinking about how to let git’s model of thinking pervade other things we do.


  1. briguy

    Agreed completely on the utility, but DAMN do we need some UX magic to make the actual mechanics of branching, comparing, and reconciling easier to execute.

    Even in cases where non-programmers (artists on a game) end up being forced to use git, I’ve noticed a real resistance to using it in any way that isn’t like dropbox. The fact that there are at least 10 different (sub-par) front-ends for git is meaningful. I think.

    I still have to look up how to do certain things in git on a regular basis, and I’ve been living in it for years.

    1. thegoldenmule

      Yes, totally. Though I tend to like the speed and reliability of a CLI, I know it’s hard to swallow for many, and there is a lot of hidden state you have to keep in your head.

      Google Docs revisions are a perfect example of a broken methodology AND broken UX. The perforce stream view is a good example, in my opinion, of a more visually minded tool, though the underlying methodology and tech… has trouble. In stream view you can visualize the graph of branches (streams) and move between them with your mouse. It doesn’t, however, let you visualize merge strategies :/

      So yah, all the tools are broken.

      1. briguy

        Agreed on CLI being a far preferable way to use git, but I also spent multiple decades of my life bending my thinking into bizarre shapes so I could more effectively interact with a processor. Probably can’t ask that of the average word processor user. I wonder if there’s almost a human-parsable AST that can be constructed to help show branches and merges of ideas.

Comments are closed.