3 ms·
I don’t understand how I’m “cheating” - at what? Character by character editing traces can be made incredibly efficient with some tweaks. Is that what you’re ge
by josephg 3y ago
I don’t understand how I’m “cheating” - at what? Character by character editing traces can be made incredibly efficient with some tweaks. Is that what you’re getting at? In the example traces I’ve gathered, the inserted characters themselves still make up the majority of the resulting file size. That is, files on disk are almost always smaller than 2 bytes per keystroke. And we can always reproduce a document at any snapshot state - quite easily, too.
I don’t have a link at the moment, but I’ve ported editing traces from git (by re-running diff match patch) and used CRDTs to do octopus style merges. They merge fine - just as you’d expect. (As I said earlier, the hard problem is adding back any conflict markers so humans can eyeball the result).
There’s nothing special in doing branches. You just only merge the set of edits (crdt messages) that show up in any particular branch’s history.
- taeric 3y agoYes, that is what I was getting at. The cheat is that none of that information is available in the snapshots. And we use the snapshot, as that is what all of the other tooling creates and works with. The fact that most people using git don't refer to the snapshots as a thing is pretty much how invisible that is to all of our tooling. It isn't a special thing, it is the thing. If you are pushing for a state based crdt that can be reconstructed from snapshots, then you aren't needing to change get as a whole, but only the diffing tool? If you want all diffs to be based on the edits users did, you aren't wanting to change get, as much as all of the tooling users use. No?