Comment by Joeri
5 years ago
My understanding may be flawed, but as far as I know you can think of an OT log and a git log as being similar. Each party generates deltas to the data structure that are recorded in the log, and when these parallel histories meet they must be merged. OT merges without involving the user, which sometimes leads it to discard changes. Git merges like that if it can, but when something must be discarded it asks the user. It is the interactive merging and deep ability to navigate and edit the log of changes that makes git so command-liney.
Not intending to nit-pick, but Git doesn't store the content as deltas. Each commit is the snapshot of the entirety of the codebase at that point in time.
Conceptually, yes, but under the hood, Git actually does store content as deltas:
https://git-scm.com/book/en/v2/Git-Internals-Packfiles
Packfiles are nothing but a compression/storage scheme - which is a couple of levels under git-objects conceptually. Saying that "git stores content in deltas because it uses packfiles" is like saying "git stores content in deltas because it uses compression". Of course it does. You'd be hard-pressed to find any tool similar in functionality that doesn't compress content before persisting it or sending it over the network.
The Linus' original insight that made git successful in part was exactly the fact that: You don't need to do the delta scheme on the VCS-object level, but you can just use it on the storage/compression level. So conceptually CRDTs are more similar to the VCSes of the past (e.g. SVN) than they are to git.
1 reply →