I clearly remember the rough days of CVS and how liberating the switch to Subversion felt all those years ago. At the time I was pretty sure that nothing would ever get as good as Subversion. As it turns out, I was wrong, and Git showed it to me! So, having learned distributed version control concepts and embraced Git, I was pretty zealous about my newfound super powers. Again, I felt sure that nothing would ever surpass it. Again, it turned out I was wrong.

At the time of this writing, Git's been with us for over a decade and a half. During that time the ecosystem has absolutely exploded. From the rise of GitHub and GitLab to the myriad of new subcommands (just look at all this cool stuff), clearly Git has seen widespread adoption and success.

So what's wrong with Git?

Well for starters, I'm not the only person who thinks that Git is simply too hard. While some apparently yearn for the simpler Subversion days, my frustration comes from working with Git itself, some of which others have been pointing out for the last decade.

My frustrations are:

• I find the git-* family of utilities entirely too low-level for comfort. I once read a quote that Git is a version control construction kit more than a tool to be used directly. I think about this quote a lot.
• Git's underlying data model is unintuitive, and I love me a good graph data structure. Conceiving of a project's history as a non-causal treeish arrangement has been really hard for me to explain to folks and often hard for me to think about. Don't get me started on git rebase and friends.
• I can't trust Git's 3-way merge to preserve the exact code I reviewed. More here and here.

Two interesting projects I've discovered recently aim to add a Git-compatible layer on top of Git's on-disk format in order to simplify things. If not to simplify the conceptual model, then at least to provide an alternative UX.

One such project is the Gitless initiative which has a Python wrapper around Git proper providing far-simpler workflows based on some solid research. Unfortunately it doesn't look like Gitless' Python codebase has had active development recently, which doesn't inspire much confidence.

An alternative project to both Git and Gitless is a little Rust project called Jujutsu. According to the project page Jujutsu aims, at least in part, to preserve compatibility with Git's on-disk format. Jujutsu also boasts its own "native" format letting you choose between using the jj binary as a front-end for Git data or as a net-new tool.

What have we learned since Git?

Well technically one alternative I am going to bring up predates Git by several years, and that's DARCS. Fans of DARCS have written plenty of material on Git's perceived weaknesses. While DARCS' Haskell codebase apparently had some issues, its underlying "change" semantics have remained influential. For example, Pijul is a Rust-based contender currently in beta. It embraces a huge number of the paradigms, including the concept of commutative changes, which made DARCS effective and ergonomic. In my estimation, the very concept of change commutation greatly improves any graph-based models of repositories. This led me to have a really wonderful user experience when taking Pijul out for a spin on some smallish-local projects.

While Pijul hasn't yet reached production-quality maturity, the Fossil project has a pretty good track record. Fossil styles itself as the batteries-included SCM which has long been used as the primary VCS for development of the venerable SQLite project. In trying out Fossil, I would rate its usability and simplicity as being roughly on par with Pijul, plus you get all the extras like a built-in web interface complete with forums, wiki, and an issue tracker.

Ultimately I prefer the Pijul model more than Fossil's but still can't realistically see either of them replacing Git.

Why I'm not ditching Git (yet)

While my frustrations have lead me to look past Git, I've come to the conclusion that I can't ditch it quite yet. Git's dominance is largely cemented and preserved by its expansive ecosystem. It's so much more than the Git integration which ships standard in VSCode and even more than the ubiquity of platforms like GitHub and GitLab. It comes down to hearts and minds insofar as folks have spent so much time "getting good at Git" that they lack the motivation to switch right now. Coupled with the pervasiveness of Git in software development shops, it's hard to envision any alternatives achieving the requisite critical mass to become a proper success.

Granted, just as Git had a built-in feature to ease migration from Subversion, Fossil has a similar feature to help interface with Git. That certainly helps, but I honestly don't know if it'll be enough.