But actually git does use diff and patch. It just doesn't store objects as diffs and patches. Whenever you do a cherry pick operation or rebase operation it syn

But actually git does use diff and patch. It just doesn't store objects as diffs and patches. Whenever you do a cherry pick operation or rebase operation it synthesises patches. You can try yourself by cherry-picking a merge commit. What even does this mean? Well, git doesn't know either because it can't figure out how to synthesise the patch unless you tell it. > If anything the lesson from git's success should be that the aurhor's approach (the diff/patch way of Subversion etc.) is exactly the wrong one. The problem with subversion was not the mechanism of storage of objects. And the strength of git doesn't lie here either. It's rather the very flexible nature of its commit metadata and it's design which builds on the idea of multiple masters. This was what was stifling in subversion. The method of storage whether of the deltas, or the individual states is trivially equivalent. You can inter-convert them if you'd like, so clearly this can't be a game changer. But even if it were and git's approach was "The Right Thing", this would not be a lesson to learn from git when dealing with data storage because it scales poorly. Every state transition would have to re-represent the entire state of the database. This will work fine for code, but for databases with tons of objects changing and being extended all the time it would be crazy. It makes a lot more sense to store the differences.