Monday, November 21, 2016

The ∞ arrows of version control

At the 0th level is a point:

The point is the current state of your source code.

At the 1th level are the arrows:

These are your commits, connected by history.

At the 2th level are the arrows between arrows:

Every time you make a change to your history, such as by creating a new commit, or deleting a commit, you create a new history, linked to the old history with a 2-level arrow.

Most VCSs don't keep track of 2-level arrows, but they could.

At the 3th level are the arrows between 2-level arrows:

You may not see the need for 3-level arrows, but that's because you never work with 2-level arrows. You like 1-level arrows because you work with points, and 1-level arrows help you keep track of your points. You don't use 2-level arrows, but you can probably see why they are useful. Everyone knows that you should never git amend after a git push. But if git kept track of 2-level arrows, you could do a 2-level push, and sync your local amend with a remote amend. You could do a 2-level revert to undo your amend. And once you start working with 2-level arrows, you need 3-level arrows to keep track of those.

There are ∞ levels of arrows.

How can the computer store ∞ levels of arrows? Won't they take up ∞ space? Just one commit creates a 1-arrow, a 2-arrow, a 3-arrow, ... and so on.

But most 2-arrows are uniquely determined by a single 1-arrow, and uniquely determine their 3-arrow. Most n-arrows are degenerate, representing only the addition of a single (n-1)-arrow. At any time, only finitely many arrows require their own representation in memory.

Can a human mind keep track of 20 levels of arrows, let alone ∞ levels? That is hard to say, because no one has tried.