Great lib. I meant libdog, a different thing. gitoxide is like "git implemented in Rust" while libdog is "git's necessary primitives in C" (objects, packs, sync proto, own index format, diff/merge, etc). As a result, gitoxide is 270KLoC while libdog is 24KLoC, plus 44KLoC of tokenizers. libdog uses token-level algorithms for diff, merge, blame. It also does syntax highlighting in the pager - they all need grammars.
The only way out is malleable software. Have the core data structures and algorithms in a native library. Have a layer of JavaScript/Lua/LISP on top of that. Editable, customizable, reusable.
This is not a theory. I work in such a system every day.
git sort of tried that with plumbing/porcelain separation and bash scripts, but it did not quite work. It all became a C monolith with very peculiar UX.
The most correct way to use git CLI is not to use it at all. All the hardcore revision control machinery better be in a C or Rust library, all the porcelain can be malleable scripts (readable, editable, customizable, extendable, reusable) [1]
You can not beat the expressive power of good old JavaScript or LISP by invoking convoluted non-standard CLI spells.
Can you pipe one git command into another? It is not even UNIX way.
As I often repeat, git's data model has Internet-standard rigor while git's "porcelain" is a disorderly mess which can hardly be fixed. Then, we put LLMs on top, resulting in a complex and expensive system that cannot be understood even in theory.
In the Beagle SCM I tried two ways to escape this trap: first, slightly readjust primitives to make things fit. That helps. Second, make the SCM malleable. Hard and performance-critical parts live in a native C lib. They implement the blob-tree-commit model, on-disk store primitives, parsers, etc. Above that, all the workflow and porcelain stuff is JavaScript in a repo. Maybe the same repo as the code! I do not need arcane options, because complex things can be expressed in (readable, editable, LLMable, and reusable) JavaScript code. People can customize it to their arbitrary needs while the core stays compact, manageable and verifiable.
JavaScript did this for the Web back in the day. I work on a malleable git-compatible SCM right now. First I put all the performance-critical parts into a native lib, then happily built my own git(hub) in JavaScript. Tastes differ, someone else may build it completely differently. I believe this is the right architecture for the LLM age.
LLM-is-a-compiler is indeed a simplistic approach. I wrote a rebuttal to the yesterday's Cursor post, may reuse it here https://replicated.live/blog/follow-up
The idea that a 835-page spec "just exists" and we run an LLM to implement it is completely flawed. Specs do not appear out of nowhere, they co-evolve with the code. If you have the code, why do you want to generate it again?
Good software is made as a product of numerous feedback loops and LLMs let you operate those loops faster. They do not supplement the entire process though.
In the end, a good product is a barrel of distilled feedback.
I am afraid the folks are still busy playing with familiar toys. "Let's extract more code out of LLM's inner layers!" SQLite we already have. That's where their "spec" came from.
The interesting frontier is elsewhere: how to fit it into the pipeline to build new useful things.
I felt motivated enough to write a follow-up/reply post http://replicated.live/blog/follow-up
Making a high-throughput revision control system is doable, there have been experiments here on HN with git-in-postgres etc. The question is, what is the actual bottleneck here?
I made a VCS for LLM assisted work, bootstrapping it on its own code as it was developed. In fact, if it did not really work, it would not even exist!
In my experience, keeping track of things and evaluating them was the bottleneck and I focused on that https://replicated.live/blog/worktree Effectively, the question is "how to leverage human evaluation and feedback".
The Cursor people concluded their last post with "taste, judgement, and direction came from humans". Sounded surprisingly sane after "don't compile it, commit it faster" some paragraphs earlier.
2*128 is the UUID namespace, which is astronomical. That is like 21 letters. Making one sentence of Shakespeare by random search is strictly 0% chance. SHA256 is ~43 letters then. "LLM broke all of cryptography and creates random data to fit a hash" -- are we there yet?
Random search does not work at this scale. In all their cases, they played with pre-existing well-studied software, so they had an embedded fitness function. An extremely detailed one.
Monkeys have been reading Shakespeare all their lives (training). Effectively, this is LLM uncompression. Hence, "in Rust, from nothing but its documentation" -- not entirely true.
2**128 is the UUID namespace, which is astronomical. That is like 21 letters. Making one sentence of Shakespeare by random search is strictly 0% chance. SHA256 is ~43 letters then. "LLM broke all of cryptography and creates random data to fit a hash" -- are we there yet?
Random search does not work at this scale. In all their cases, they played with pre-existing well-studied software, so they had an embedded fitness function. An extremely detailed one.
Monkeys have been reading Shakespeare all their lives (training). Effectively, this is LLM uncompression.
Back in the day I actually read that, but after an hour or two it wears you down, you start okaying stuff. These days I refuse to read. The policy says "one paragraph unless explicitly requested". If it does not understand the policy, is there any point in reading that?
Thanks, fixed. The runtime[1] and the scripts[2] are the practical ones. I am separating the old repo[3] into submodules since submodule recursion became smooth in Beagle.
http://replicated.live
@gritzko on Twitter, Telegram, Bsky
https://bsky.app/profile/gritzko.bsky.social
eddsa263/66a66a20ab3cb789d761c192ddcbb02f4567e382