Jujutsu for everyone

I happened to listen to a podcast episode yesterday where the topic was Git rebase. There were 4 people in the panel. One person made a point that he did not understand why they even care, saying basically Git is broken, all the VCSs are broken because they are too complicated and they get in the way. He said a lot of things but my take was that all the existing VCSs are just a distraction. I personally don't agree with him. But while listening to his argument, I started imagining a perfect VCS which is not Git, JuJutsu, perforce, or whatever.

This got me thinking why I have not tried Jujutsu yet (which was mentioned in the episode briefly) even after I saw it multiple times on HN over the years. It is probably because it just looks like another Git, maybe a less complicated one. But nonetheless it's going to be Git-like, and I know enough about Git and am competent with it. So there is little incentive to learn and try another Git-like tool.

I would love to try a VCS vastly different from Git. But it cannot be just different, it should be better than Git. That, I think, is hard to come by.

By the way, if anyone is interested which podcast I am talking about, this is the episode. "The Real Problems w/ Git" on ThePrimeTime. https://youtu.be/t6qL_FbLArk?si=GOkixm86rFADoc4x

I didn't think that there was something wrong with my git workflow, or that git was complicated. I switched from darcs as my primary VCS to git around 2007. I was skeptical about jj at first but gave it a try. Did not look back ever since.

My impression is, that git is ok for managing shared history. And thats what i was using it for mostly. But jj added another whole dimension for managing my work in progress, different paths of code that i am working on in the moment. jj made it almost frictionless. I did not know I was missing it, but i'm not going back.

I listened to the same podcast, and agreed with the points that Casey made. However, there were some aspects of version control that were glossed over.

What was described was actually quite close to developing through a Dropbox folder + (implied) tooling. And that makes a lot of sense for Casey Muratori's current work, which I believe is a small 5-10 person team doing game (engine) development. Such teams can quite easily work all in the same source branch (and this could in fact be preferred, e.g. for large assets in gaming).

However, as organizations grow, you want different levels of staging (that could be provided by your version control). A split between local and _the common_ stream, release branches, splits between projects or features, review states, etc.

So I believe the optimum is somewhere in the middle, and jj does take a step towards it. But still some friction remains.