GitEngine, a repository as a braided river

Git rebuilt from first principles in Go, surveyed like a river system. Branches are channels, commits are confluences, the object store is the sediment. Every hash is a real SHA-1, computed in this tab.
Working tree clean.
Sediment recordthe object store, newest on top in each core. Click any stratum for its core sample.
Commits
Trees
Blobs
Survey commands
Field notebook README.md
Survey log status, add ., commit -m 'msg', log, branch, checkout, merge, cat-file, help
ge
Core sample HEAD main
Click a confluence or a stratum.

What you are looking at

GitEngine is Git's core, written again from first principles in Go: a content-addressed object store, an index, refs, and seventeen commands including three-way merge with diff3-style conflicts and rebase. The chart above is a live repository running in your browser. The hashing is not imitated: every object is serialized exactly the way Git serializes it and hashed with SHA-1, so the hashes you see are the hashes native Git would produce for the same bytes.

Read it downstream. The headwaters are your working tree, one tributary per file. The staging pool is the index. The channels are branches, and each gold marker is a commit: a confluence where the pool's contents joined the record. The sediment is the object store itself, every blob, tree and commit laid down as a stratum with its hash.

How the river reads

  1. Edit a file in the notebook. Its tributary marks itself changed.
  2. add . stages it: the file's content is hashed into a blob and the pool level rises.
  3. commit writes a tree from the pool, then a commit object pointing at that tree and at its parent. A new confluence appears on the channel, and the new strata glow gold for a step.
  4. branch exp then checkout exp opens a second channel from the same confluence. Commits on it braid away from main.
  5. merge exp finds the merge base by walking both ancestries, then joins the two channels. If both sides changed the same lines, the join becomes rapids: conflict markers land in the file, and the next commit seals the merge with two parents.

Try this

  • Let the demo braid and merge on its own, then click the merge confluence. The core sample shows a commit object with two parent lines, which is all a merge commit is.
  • Click any blob stratum. The core sample prints the exact printf | git hash-object --stdin command; paste it into a terminal with real Git and the hash will match.
  • Force rapids yourself: checkout exp, edit README.md, add ., commit -m 'exp', checkout main, merge exp. Both channels changed the same file, so the merge stops and asks you.
  • Drop a real text file onto the page. It lands in the headwaters, untracked, until you add it.

Gauge readings, measured

Parity with native Git is proved by a differential suite that runs every scenario through both GitEngine and git and compares the resulting hashes: commit chains, merge bases, merge commits and rebased tips are identical byte for byte. The suite caught three real encoding bugs on its first day, which is why it exists.

Differential parity with native githash-identical scenarios
15 of 15
Bulk ingest of 2,000 filesagainst 706 ms for git, on the repository's harness
349 ms
Integrity checkfsck over the whole store
28,555 objects/s
Concurrent writersindex locking with atomic renames
8, 0 lost updates

To check it: clone the repository and run go test ./difftest/. It needs a real git on your path, because that is what it compares against.