Are there any endeavors to decouple VCS interface from the implementation? An analogy is LLVM, but for VCS, in terms of modularizing the architectural layers. It’s difficult justifying learning a new VCS when popular open source projects and employers select for particular systems. Surely there are tradeoffs, but enabling developers to use a familiar interface such as Git would reduce the friction of adoption, while still providing the benefits associated with a particular implementation that’s suited for the project.
That's a lot of text not to mention Darcs, which I believe introduced the "unordered set of patches merged by mathematical theorem" [1] 15 years ago.<p>I was a heavy Darcs user for a while before switching to Git. The biggest flaw in the "set-of-patches" model IMHO is the inability to quickly compare the state of two repositories. With Git, this is trivial -- since commit hashes represent the entire history, just compare them. With a Darcs-style VCS, you're limited to only comparing patch sets that have been explicitly tagged, or comparing the repositories patch by patch. And the existence of rebasing (which is sometimes necessary even in Darcs-style repos) pretty much negates the main benefit of the set-of-patches model.<p>[1] <a href="https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory" rel="nofollow">https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...</a>
That was weird: an hour ago I was reading "Version Control with Git" about merging and thinking "Hey, this is all just category theory", I then have a look at HN, and see this.