3 ms·
There's a lot of factions doing git backed or git like systems out there already. LogRocket has a round-up of 9 different CMS, such as the excellent excellent T
by jauntywundrkind 1y ago
There's a lot of factions doing git backed or git like systems out there already. LogRocket has a round-up of 9 different CMS, such as the excellent excellent Tina CMS. The #GitOps is incredibly well loved & respected for all manner of systems & infrastructure, with projects like ArgoCD being immensely popular. https://blog.logrocket.com/9-best-git-based-cms-platforms/ https://blog.logrocket.com/9-best-git-based-cms-platforms/ https://tina.io/ https://tina.io/ https://argoproj.github.io/cd/ https://argoproj.github.io/cd/
There's countless git-like data systems. Dolt DB, LakeFS, and notably Iceberg has branching. https://github.com/dolthub/dolt https://github.com/dolthub/dolt https://lakefs.io/ https://lakefs.io/ https://iceberg.apache.org/docs/latest/branching/ https://iceberg.apache.org/docs/latest/branching/
My experience is the pushback that git is too complex, git is for programmers is enormously fast to follow most suggestions on using git. I remain enormously skeptical. There was a zeitgeist floating around a week or two ago about the worst thing you can do is to make decisions on the assumption that people are stupid, and git is a place where I absolutely believe we can outshine the rain, and will wonder why we ever let such doubt guide us away from such an amazing set of capabilities with such amazing tooling. We have such a start already with git tools! Once we try, we can keep humanizing this!!
My pet theory is that much of the weakness of git for everyone is that we do a terrible job of expressing data on the filesystem. It's popular & so reasonable to be able to copy a document to someone, but in my mind, ideally a document is maybe a file tree of sections or paragraphs, that the editor kindly manages for us. We'd need a general container format (OCI?) to give us lots of small files but still nicely wrapped into one. A 9p everything-is-a-file philosophy is semi known, has believers, but decomposing big data splats into smaller pieces, such that individual fields and bits and bobs of the data can be scripted: that is a shift to exposes the data, & is a necessary core accompaniment for any 9p-ification. Together, small/decomposed visible data on the filesystem unlocks people's ability to see what stuff is without the crutch of one and only one special purpose application, is a bridge to making much more of humankind more of an expert (or at least capable dabbler!) at computing, opens up broader realms of scripting & interaction that we've kept locked away, locked inside the process, only for developers to sometimes peer at. Git is weak because our data is encoded in countless bespoke ways, not visible on the file system. (It doesn't have to be that way.)
Regardless, programming itself has a lot of gains to make. Making the object model in programming languages version aware is a huge lift I really hope to see happen some day. This submissions is about improving the rest of the world, but programmers and languages should do for themselves, should lead the way. I started this post by citing lots of git related efforts, but these are libraries, are layers atop, and pushing versioning down down down into the runtime-i feel- is where we really need version control: right from the start, in the base. (More intuitive sense here, would love more developed structured argumentation on this).
Globally addressable (beyond the process boundary, beyond the machine boundary) object spaces, with version control, feels like some omega point for computing, where we go from bespokely layering together complex systems and capabilities, to having a language that can express and work through the range of materials that actually make up the computing world as it is. A better compute is possible.