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

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.