Work the thing

I have worked with revision control and on revision control systems for quite some time now and I had every opportunity to develop strong opinions. Many of those opinions have changed as parallel LLM development became the norm. Tomorrow, the process will likely evolve even further. So, how do I see modern revision control? Can I really have any stable opinion here?

The only stable thing now is constant change. How can source code management help here? Should we use worktrees, patch stacks, CRDT merges, trunk-based development? The correct answer is that I do not know what will work tomorrow. So the revision control system must, first and foremost, be adaptable to any new process, including project-specific processes.

Beagle, the revision control system, is built to fit this exact condition. There is libdog, the layer of fast and deterministic tools of the trade: git compatibility, source code tokenization, indexing, data exchange format, diff and merge algorithms. There is a minimalistic JavaScriptCore-based JS runtime JAB. I do not use node.js and others because of their weight and ridiculous supply chain issues. Finally, on top of JAB there is the malleable part - the revision control system itself. Beagle is made in a very specific way - it uses an orthogonal basis of HTTP verbs (GET, HEAD, POST, PUT, PATCH, DELETE) to do any work and URIs to address any resource. The runtime itself can execute any "verb", so diff, status, list, log and many other normally expected things are there. In fact, I write it as I go. I need a tool, I tell Claude to make a tool.

So the stack is like this:

beagle - malleable JavaScript, user facing, changes fast;
JAB - JavaScript bindings, rare changes for new APIs;
libdog - source code management toolkit, rare changes, fuzzed, C;
libabc - C dialect, OS API wrappers, textbook algos, may not see a change in a month.

Changes to libabc I carefully read, changes to libdog I look at, beagle I can vibe. This way I keep the actual behavior malleable without devolving the codebase into slop. Frankly, Netscape invented JavaScript exactly for this kind of use.

Yesterday I wanted a new blame view. It took me a couple of hours, and I called it why. Because, when you work with LLMs, you can only blame yourself! It is all JavaScript, all the heavy lifting is done by the libdog backend, and it works. If I do not like how it works, I can tell Claude to correct things. JavaScript is sufficiently safe and malleable to make this process painless. In fact, that became the norm: I have a terminal to work on a thing and another terminal on the side to work the tool to work the thing.

Beagle likes dogfood!