Six months of using Jujutsu

I've been using Jujutsu (jj), on a near daily basis for the last six months, effectively as a git client for my work's git repos. Overall, I really like it and would recommend it as a significant improvement on Git but it is not without its sharp edges.

Jujutsu has become indispensable for my workflow when juggling multiple pieces of work. Whether I'm building stacked diffs in series or working on parallel features, Jujutsu handles complex branching scenarios with elegance that Git simply can't match. The merge commits are refreshingly simple to create and reason about (though I do wish there were a way to remove a single parent from a merge commit when reorganizing work).

Git compatibility

The standout feature of Jujutsu is its exceptional Git compatibility. This isn't just "works with Git repositories" compatibility — it's seamless, bidirectional interoperability that lets you have your cake and eat it too. I can enjoy all of Jujutsu's benefits while my colleagues continue using their familiar Git workflows without any disruption.

This compatibility is what makes Jujutsu genuinely viable for real-world adoption. Too many promising tools fail because they require team-wide migration, a nearly impossible hurdle in most organizations. Jujutsu sidesteps this entirely. When I commit changes using jj, my teammates see normal Git commits. When they push changes, I can pull them seamlessly into my Jujutsu workflow. It's the rare migration path that doesn't feel like migration at all.

Tooling

However, there's a significant caveat that prevents me from recommending Jujutsu for everyone: editor integration is practically nonexistent. With Jujutsu, you're back to the command line for everything, which is fine for me but is not how a lot of devs interact with Git. This is particularly painful when editors can provide smoother workflows for interactive rebasing, cherry-picking, or resolving merge conflicts. These workflows, which feel natural in a well-integrated environment, can become cumbersome when relegated to command-line tools.

Accidental Commit Editing

My biggest practical frustration with Jujutsu centers around accidentally editing commits I've already pushed. In Git, you explicitly create commits where in Jujutsu, you're always working within a commit, and jj new creates a fresh commit for new work. This means forgetting to run jj new after completing a change results in accidentally editing your previous commit, including commits you've already pushed to shared repositories.

While Jujutsu does have immutable commits as a feature, the setup isn't intuitive, and the defaults don't prevent this common mistake. I've lost count of how many times I've caught myself accidentally amending a commit I meant to leave alone. The problem is exacerbated by the fact that Jujutsu makes editing commits so easy that it becomes muscle memory, until you realize you've edited the wrong one. Whilst this can be fixed with jj undo or jj split -i it's still annoying.

What I'd love to see is a more aggressive default behavior around commit immutability, or at least a prominent warning when you're about to edit a commit that exists in a remote repository. Some kind of "commit finalization" workflow would be ideal; perhaps automatically running jj new after pushing, or requiring explicit confirmation before editing commits that have been shared or haven't been touched for a few hours.

Verdict

Jujutsu represents genuinely innovative thinking about version control, and its Git compatibility makes it uniquely practical among Git alternatives. I think it's good enough for everyday use on production codebases, and I'd recommend developers give it a try, especially if you're already comfortable with command-line Git workflows.

The lack of editor integration hasn't been a major issue for me personally, since I never relied heavily on visual Git clients to begin with. However, this would undoubtedly be a deal-breaker for developers who depend on the rich ecosystem of Git tooling integrated into their editors and IDEs. If you're someone who lives in VS Code's Git panel or relies on sophisticated merge tools, Jujutsu might feel like a significant step backward and might not be worth it.

The accidental commit editing issue is more universally problematic and represents the kind of sharp edge that could catch any user. Better defaults around commit immutability would go a long way toward making Jujutsu more robust for daily use.

Despite these shortcomings, Jujutsu's foundation is solid and its Git compatibility is genuinely game-changing. For command-line focused developers working on teams that use Git, it offers a more intuitive and powerful interface without the typical migration headaches. The tool is ready for real work — just be aware of its current limitations and whether they align with your workflow preferences.