4 ms·

> Ideally I’d like tools like git to eventually be replaced by CRDT based approaches. CRDTs would let us use the same tools to do pair programming. CRDTs also h

> Ideally I’d like tools like git to eventually be replaced by CRDT based approaches. CRDTs would let us use the same tools to do pair programming. CRDTs also handle complex merges better (no self-conflicts like you can get with git). And they’re generally a more powerful model. I'd be interested to see how this plays out in practice. It seems to be in conflict with the idea that scm history is a meaningful deliverable that should be arranged as series of incremental atomic changes before a patch series leaves your development machine. However, most developers I interact with already treat git history as an infinite editor undo history, this approach seems like it would crystalize that fact. How do you envision the (long-term) history working? Do you think it would provide more/less utility?

josephg 3y ago
I’ve thought a lot about that. Personally, I think it’s silly that people try to use git’s history for two different purposes: 1. An audit log of what actually happened, and when 2. A curated story of features added and changed I don’t think git can be both of those things at the same time already. And we see this tension play out when people argue about squishing commits and rebasing before merging. Personally I think both pieces of information have value. And they should be managed separately - as different features. Eg Git could (and perhaps should) have a second semantic layer which marks a set of commits (atomic history of changes) as semantically associated with a particular feature or issue. This is how I imagine a crdt based scm working: the history of all changes is stored immutably, and synchronised. And change sets can be grouped and marked as “this set of changes is associated with feature XXX”, to make it easier to understand the intent behind code, and roll back specific change sets.
- reverius42 3y ago
  > Eg Git could (and perhaps should) have a second semantic layer which marks a set of commits (atomic history of changes) as semantically associated with a particular feature or issue. It does (sort of)! They're called branches and tags.

josephg 3y ago

I’ve thought a lot about that. Personally, I think it’s silly that people try to use git’s history for two different purposes: 1. An audit log of what actually happened, and when 2. A curated story of features added and changed I don’t think git can be both of those things at the same time already. And we see this tension play out when people argue about squishing commits and rebasing before merging. Personally I think both pieces of information have value. And they should be managed separately - as different features. Eg Git could (and perhaps should) have a second semantic layer which marks a set of commits (atomic history of changes) as semantically associated with a particular feature or issue. This is how I imagine a crdt based scm working: the history of all changes is stored immutably, and synchronised. And change sets can be grouped and marked as “this set of changes is associated with feature XXX”, to make it easier to understand the intent behind code, and roll back specific change sets.

reverius42 3y ago
> Eg Git could (and perhaps should) have a second semantic layer which marks a set of commits (atomic history of changes) as semantically associated with a particular feature or issue. It does (sort of)! They're called branches and tags.