Jujutsu: A Next Generation Replacement for Git

This getting spammed but developers .. they are afraid to change from git . Mercurial was much better than git in workflow and architecture wise and nobody care enough due to GitHub popularity. This will go the same , as well as sapling.

As a counterpoint, jj has extremely good git interoperability.

I and another teammate have switched over for several months and nobody on our team needs to know or care.

Props to you, but this doesn't change my mind. VCS is intrinsically meant as a collaboration tool. If something goes wrong "jj did it" won't be a good excuse. If one needs to communicate his workflow to another, he better doesn't start with "well, you just install jj and...", he needs to explain, how to do that in git. If there is a junior dev on the team and I need to teach him common practices, I need to do that in the same personal-preference-agnostic manner, so I shouldn't teach him jj instead of git, even if I use it personally. Long story short, you need to be fluent in both, and even though I know git pretty well, I wouldn't even say I'm fluent in git: most of the time my fingers type stuff I don't conciously remember anymore, often relying on aliases and Ctrl+R. This is additional complexity, and it feels to me like I need it to be something HUGE to actually justify that.

Honestly this is a ridiculous take.

Git is the native backend for jj. It is extremely reliable. There is no reason for "things to go wrong" uniquely to jj, particularly if you take basic precautions like forbidding force-pushes to master/main. For that matter plenty of people make mistakes with git itself, and having used both (and being a power user of git) I can confidently claim that there is significantly less surface area for mistakes with jj than there is with git.

I have never, in 25 years of software development, needed to "communicate my workflow" with another engineer. It's understood that if I use a different tool than the rest of my team, I'm on the hook for knowing any differences in the workflow. But it's not even like this is unique to jj; my team uses a variety of editors/IDEs, operating systems, and shells. I use macOS, fish, VS Code, and jj. Others use nix, zsh, vim, and git. Somehow we all manage.

The worst part is that your argument is trivially rewritten to discourage trying anything new. This is frankly a terrible mindset to have.

If you don't want to learn a new tool, by all means don't. But not learning anything that might be different than what other people on your curent team use is a great way to completely stagnate your growth.

That said, the argument I was responding to was that this can never take hold because of git's dominance. My point was that use of jj can grow organically since one person converting doesn't actually require the entire team to do so. Whether or not you're particularly hesitant to adopt new things is irrelevant; individuals can switch whenever they feel appropriate and it doesn't impact others.