`jj` has done git users an amazing service simply by being a more intuitive VCS front-end is possible.
What in the world... why?
I prefer mono-repos personally, but they have the downside of being very busy and bulky because of that. Doing a partial clone by folder is very clunky at best, and there is no per-folder notion of permissions, which makes this a total non-starter for my team. The result is that we have thousands of repos and tooling that helps you check them all out into the correct place to make builds across them work. And inevitably they get out of sync and the builds break.
Git submodules seem like a solid approach, allowing you to cobble a bunch of poly-repos into something that kind of looks like a mono-repo, but the tooling support around it just makes it super painful, and you still don't have the ability to have an atomic commit across the repos. And people *hate* submodules.
I don't know the solution, but I wish this was on the radar of people who know git better than I. For now I'll just bumble through the repos I need to touch.
There has been efforts to store git repos in torrents, and to store got repos on crypto blockchains, but all are big architectural challenges, for example people want everything to be backwards compatible for starters, and some want to be able to partially store some content somewhere else, while still keeping all existing use cases efficient.
I've successfully gotten many non tech roles to use git but there's usually a lot missed in the nuances and power that is in their reach, but not quite adopted.
The learn git branching site/game [1] has always been an awesome resource but you'd like something like that UX be almost part of the initial usage. Intuitive defaults, progressive learning at the right times, etc.
Nowadays, if you can get your users to use an agent CLI like Claude/Codex/OpenCode then it's easier to have that last experience but the more git itself uses accesible abstractions the easier it should be.
There are a lot of other different metadata that you could imagine to store per commit, but git already supports storing arbitrary data in every commit, you don’t need special casing for some type of metadata, just store it in the commmit as everyone already does, and perhaps build your own tools on top of that if you have special needs.
Co-Authored-By: Whatever LLM
License: WTFPL
