Losing (Version) Control
git rekt m8
They say you haven’t lived if you haven’t lost code by accident. It’s happened to me. It’s happened to these distinguished programmers:
In case you didn’t know, these two are excellent programmers: Patrick is writing a language (dat type system) and Tim is writing a code editor (probably making this post redundant).
So, have you ever lost code by accident?
If your answer is “no”: You are a god. You bask in the glorious power of being able to go back and forth in time itself. You laugh at humanity’s inability to do as you do. “Ah, to be a god”, your godly brain manifests.
If it’s “yes”: Welcome to 2014. Gigabytes worth of GIFs are transferred to your array of personal computing devices daily, yet nothing is keeping track of the few precious kilobytes you typed into a dark window. But this is madness! Typing code is your job. It makes your brain hurt. It’s one of the few things a computer cannot figure out for you (congratulations on the job by the way). How is this not important?
You might still think you don’t have a problem. Let’s look at a few variants of “losing code”:
- git regret: Hard resetting and/or checking out your working copy without ever having stashed, staged or committed your changes. The reflog will laugh at you.
- git headache: “Oh, too bad, I thought the working version was still in my editor history. I should have made a commit. If I just knew how to use this undo tree thing properly... I should ask Hans to show me again how it works. Oh, Hans quit his job to work at that version control company because he was so good at it.” A variant of this: “I need to get back to that version. I will step back and forth in history very carefully without accidentally pressing a key that will disrupt my precious editor history. Oh, hello kitty. Have you come to step on my keyboard again, threatening my sanity?”
- Local hardware failure: Having committed or stashed your work will open up possibilities to the awesome power of git’s reflog. But not pushing your precious code won’t protect you from hardware failure. Can you hear that silent mocking laughter? It’s the reflog, amused at your incompetence.
To mitigate these problems I propose a system with the following properties:
- Universality: Record all changes. When editing code, record every key press/paste. When changing dependencies, record every version change. Every edit will be recorded as an atomic change and added to a sequence. Nothing is excluded from this. You can create logical commits from this atomic change history later, making it look however you want.
- Interface/Visibility: Allow navigating change history. You can see a list of relevant past versions and easily peek at and restore older versions. You see which versions passed your tests and other quality metrics.
- Durability: Replicate change history to a persistent service (Dropbox, Google Cloud, S3, github). All the time. By default. Disk failures and network partitions won’t matter anymore. Your things will already be somewhere safe and you know it. You can stop being conscious about your “local history” because there is no such thing anymore. You can focus more on the task at hand.
- Privacy: Keep change history private. Nobody but you will be able to follow your horribly embarrassing trail of thought. You decide what becomes a logical commit or a published version.
I believe git could play a major role in such a system. What we’re currently lacking is the glue between your editor, your working copy, your git index, your local git branches and your git remotes. But honestly, this sounds hard, maybe impossible. For example, how to respect privacy when pushing to a github repo with collaborators? I can’t think of an easy way to fix this.
Changing the system’s primitives
Here’s something I’d like to be able to do:
Pack my iPad, ride my bike for an hour and be able to work on my code from a nice place (like a Biergarten, a magical place where you may bring your own food and buy their beer). Changing code makes your tests run in the cloud with instant feedback. Deployment happens when tests have passed.
This isn’t about some code editor app changing a file in Dropbox. I want to be able to create a true new version of a module in version control.
I think this requires a change to our version control primitives: How we represent code, versions and relationships between modules.
What if the representation of code never was files on disk (how we use git) but always records in a replicated, indexed database (how people are going to explain git to me in the comments)?
I’ll address the four system properties from above with those vaguely specified primitives:
- Every change creates a new version
- Provide an interface for interacting with the version history (undo/redo/compare/rollback)
- Replicate changes to multiple private remote peers
- Only replicate explicitly published/verified changes to public or shared remote peers
I’m interested in your thoughts on this madness and I might be writing more about this in the future.
If you’re at JSConf EU 2014 this weekend come and see my talk on Saturday at 18:15. I‘ll be talking about this and other topics contributing to the human condition.
Indeed, let us despair together.
