Hacker News: gritzko

New comment by gritzko in "How to build a `Git diff` driver"

gritzko — Sat, 11 Apr 2026 20:01:35 +0000

I recently implemented a diff driver as part of git-dogs. The integration part Claude one-shotted.

Mine is token based: https://replicated.wiki/blog/img/difflet.png

The set of git tools itself, very much in development: https://github.com/gritzko/git-dogs

New comment by gritzko in "I imported the full Linux kernel git history into pgit"

gritzko — Thu, 09 Apr 2026 12:28:28 +0000

I was giving students an assignment to import git repo into fossil and the other way around. git was a tad faster, but not dramatically.

New comment by gritzko in "Spot – Git repo code search, replace, diff and merge"

gritzko — Sun, 29 Mar 2026 17:28:47 +0000

It can use multiple cores for a full reindex. On each commit, it reindexes affected files.

Spot – Git repo code search, replace, diff and merge

gritzko — Sun, 29 Mar 2026 17:14:45 +0000

Article URL: https://github.com/gritzko/librdx/tree/master/spot

Comments URL: https://news.ycombinator.com/item?id=47565073

Points: 2

# Comments: 3

Spot – git repo AST-aware index, search and replace

gritzko — Fri, 27 Mar 2026 22:20:13 +0000

Article URL: https://replicated.wiki/spot/

Comments URL: https://news.ycombinator.com/item?id=47549139

Points: 1

# Comments: 0

New comment by gritzko in "The future of version control"

gritzko — Sun, 22 Mar 2026 19:52:41 +0000

In 2007 Bram said to me that my Causal Tree algorithm is a variant of weave. Which is broadly correct. In these 20 years, the family of weave-class algos grew quite big. In my 2020 article, I devoted the intro to making their family portrait https://arxiv.org/abs/2002.09511 Could have been a separate article.

New comment by gritzko in "[dead]"

gritzko — Fri, 20 Mar 2026 06:37:34 +0000

Fresh account, no history, AI avatar, a vibed project suspiciously similar to some existing project. Is this the new norm?

https://github.com/gritzko/librdx/tree/master/be

New comment by gritzko in "RX – a new random-access JSON alternative"

gritzko — Thu, 19 Mar 2026 10:47:26 +0000

I recently created my own low-overhead binary JSON cause I did not like Mongo's BSON (too hacky, not mergeable). It took me half a day maybe, including the spec, thanks Claude. First, implemented the critical feature I actually need, then made all the other decisions in the least-surprising way.

At this point, probably, we have to think how to classify all the "JSON alternatives" cause it gets difficult to remember them all.

Is RX a subset, a superset or bijective to JSON?

https://github.com/gritzko/librdx/tree/master/json

New comment by gritzko in "Lies I was told about collaborative editing, Part 2: Why we don't use Yjs"

gritzko — Mon, 16 Mar 2026 14:13:06 +0000

When I was starting my research into collaborative editing as a PhD student 20+ years ago, rebase-and-resubmit was well known. It was used in one Microsoft team collab product (I forgot the name). It is 100% legit algo except intermittently-connected clients may face challenges (screw them then).

Unless you have to support some complicated scenarios, it will work. I believe Google Docs initially used something of the sort (diff-match-patch based). It annoyed users with alerts "lets rebase your changes", esp on bad WiFi. So they borrowed proper OT from Google Wave and lived happily since (not really).

One way to think about it: how many users will your product have and how strange your data races / corner cases can get. At Google's scale, 0.1% users complaining is a huge shit storm. For others, that is one crazy guy in the channel, no biggie. It all depends.

TLDR: people invented OT/CRDT for a reason.

New comment by gritzko in "Lies I was told about collaborative editing, Part 2: Why we don't use Yjs"

gritzko — Mon, 16 Mar 2026 14:03:06 +0000

At least Yjs, Loro and Automerge must handle some degree of operation reordering. Either causally-consistent or virtually any order.

New comment by gritzko in "Lies I was told about collaborative editing, Part 2: Why we don't use Yjs"

gritzko — Mon, 16 Mar 2026 11:31:15 +0000

One way to minimize impedance mismatch is to work with DOM-like or JSON-like structures mostly immune to transient bugs, which I am doing currently in the librdx project. It has full-CRDT RDX format[1] and essentially-JSON BASON[2] format. It does not solve all the problems, more like the set of problems is different. On the good side, it is really difficult to break. On the bad side, it lacks some of the rigor (esp BASON) that mature CRDT models have. But, those models are way more complex and, most likely, will have mismatching bugs in different implementations. No free lunch.

[1]: https://github.com/gritzko/librdx/tree/master/rdx [2]: https://github.com/gritzko/librdx/tree/master/json

New comment by gritzko in "Lies I was told about collaborative editing, Part 2: Why we don't use Yjs"

gritzko — Mon, 16 Mar 2026 11:22:48 +0000

The actual point of the post: Y.js is slow and buggy.

New comment by gritzko in "Kotlin creator's new language: talk to LLMs in specs, not English"

gritzko — Thu, 12 Mar 2026 14:36:07 +0000

So is it basically Markdown? The landing does not articulate, unfortunately, what the key contribution is.

New comment by gritzko in "Beagle, a source code management system that stores AST trees"

gritzko — Mon, 09 Mar 2026 07:01:25 +0000

Tree-sitter can parse somewhat-bad code.

Also, there is an option to pick a codec for a particular file. Might use tree-sitter-C, might use general-text. The only issue here, you can't change the codec and keep nice diffs.

So, these cases are handled.

New comment by gritzko in "Beagle, a source code management system that stores AST trees"

gritzko — Mon, 09 Mar 2026 01:41:56 +0000

I cannot remember a case, in the last 10 years at least, when I committed code that does not compile. Why should I share that? Also, tree-sitter sort of handles that.

New comment by gritzko in "Beagle, a source code management system that stores AST trees"

gritzko — Sun, 08 Mar 2026 19:07:56 +0000

(Author) There is a fall-back general-text codec: tokens, no AST (e.g. for Markdown). If that fails (non UTF8), there is the general-blob final-fallback codec (the git mode).

The way it makes an AST tree is non-lossy. Additionally, it stamps ids on the nodes, so merges do not get confused by renames, formatting changes and similar things. There is value in preserving structure this way that repeat parsing can not provide. In big-O terms, working with such an AST tree and a stack of its patches is not much different from stacks of binary diffs git is using.

If I have k independent changesets, I have k^2 unplanned interactions and 2^k unplanned change combinations. Having a bunch of change sets, which I had not fully evaluated yet, esp in relation to one another, I would like k-way merges and repeat-merges to be seamless, non-intrusive and deterministic. git's merges are not.

The project is experimental at this point.

New comment by gritzko in "Beagle, a source code management system that stores AST trees"

gritzko — Sun, 08 Mar 2026 18:46:40 +0000

CRDT's trick is metadata. Good old diff guesses the changes by solving the longest-common-subsequence problem. There is always some degree of confusion as changes accumulate. CRDTs can know the exact changes, or at least guess less.

New comment by gritzko in "Beagle, a source code management system that stores AST trees"

gritzko — Sun, 08 Mar 2026 18:36:09 +0000

For one merge, yes. The fun starts when you have a sequence of merges. CRDTs put ids on tokens, so things are a bit more deterministic. Imagine a variable rename or a whitespace change; it messes text diffing completely.

New comment by gritzko in "Sem – Semantic version control. Entity-level diffs on top of Git"

gritzko — Sun, 08 Mar 2026 11:37:52 +0000

Was "sem" named "graft" last week and "got" a week before that? Everyone is vibing so hard it is difficult to keep track of things. Also, idea theft gets to entirely new levels. Bot swarms promote 100% vibed stolen projects... what a moment in time we all enjoy.

Still, my two cents: Beagle the AST-level version control system, experimental

https://github.com/gritzko/librdx/tree/master/be#readme

It genuinely stores AST trees in (virtually any) key-value database (RocksDB at the moment). In fact, it is a versioned database for the code with very open format and complete freedom to build on top of it.

be is in fact, more of a format/protocol, like in the good old days (HTTP, SMTP, XML, JSON - remember those?)

New comment by gritzko in "Ki Editor - an editor that operates on the AST"

gritzko — Sat, 07 Mar 2026 18:00:53 +0000

I work on AST based revision control. I have a stack of ideas on how to achieve the same Ctrl+W effect with commits/diffs/cherry-picks. All still in flux. If you have some thoughts to share, please do.

[1]: https://github.com/gritzko/librdx/tree/master/be#readme