> Looks like operational transforms to me.
Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists.
> The doc claims it's the first with this technique.
More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin.
> A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave.
Darcs is Pijul's ancestor, and I mentioned Pijul. I also mentioned the weave and how reference sets scale better.
> The example in the doc uses text, and unfortunately I think it's for a reason.
Readability. Nothing more. The real stuff will be a compact binary format.
> I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency.
Yore will dedup change data instead because as the Lore document itself identifies, dedupping content is hard using chunks; you either get dedupping or canonical addresses. Change data doesn't have one canonical address; the address is in the commit data instead.
Dedupping changes has another benefit. If most instances are "replace A with B," and A replaces B in multiple places, Yore will be able to store just one instance of A, no matter its size. This matters because the larger the chunk, the less likely it will match any other chunk.
> Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.
True, but that should be table stakes. The fact that Git does not is a poor reflection on Git, not an innovation in Lore.
[1]: https://www.stacking.dev/