If you fetch from a repo with a slightly different history for a named branch than what you have locally, git fetch will fail. Thus git fetch operations are not part of a CRDT.
Similarly, the order in which you synchronize (fetch or merge) from remote sources is order dependent and does not eventually converge to the same result (e.g. the commit hashes will diverge for a simple reason that the current time is part of the commit hash).
This is even more true for git merge which does not even attempt automatic conflict resolution if the same file is edited multiple times.
Automatic conflict resolution is a key requirement of CRDTs and another is that when nodes are brought online they are guaranteed to converge to the exact same state. This is demonstrably not true for git & trying to handwave it away doesn't change anything.
Not sure why you're trying to shoehorn git into the CRDT definition when it's its own thing.
> What I'm describing here is very similar to decentralized version control (e.g., git and mercurial). In git, you commit locally and eventually merge and push your changes into a remote repository. Unlike git, CRDTs don't have merge conflicts. Conflict resolution is handled by the CRDT algorithm itself. Although not exactly a CRDT, git will be a useful model to refer back to since it is something already familiar to most developers and incorporates similar concepts.
Similarly, the order in which you synchronize (fetch or merge) from remote sources is order dependent and does not eventually converge to the same result (e.g. the commit hashes will diverge for a simple reason that the current time is part of the commit hash).
This is even more true for git merge which does not even attempt automatic conflict resolution if the same file is edited multiple times.
Automatic conflict resolution is a key requirement of CRDTs and another is that when nodes are brought online they are guaranteed to converge to the exact same state. This is demonstrably not true for git & trying to handwave it away doesn't change anything.
Not sure why you're trying to shoehorn git into the CRDT definition when it's its own thing.
> What I'm describing here is very similar to decentralized version control (e.g., git and mercurial). In git, you commit locally and eventually merge and push your changes into a remote repository. Unlike git, CRDTs don't have merge conflicts. Conflict resolution is handled by the CRDT algorithm itself. Although not exactly a CRDT, git will be a useful model to refer back to since it is something already familiar to most developers and incorporates similar concepts.
https://vlcn.io/blog/intro-to-crdts