Jujutsu and Git [LWN.net]

Jujutsu and Git

Posted Feb 13, 2026 21:52 UTC (Fri) by jc2026 (subscriber, #182142)
In reply to: Jujutsu and Git by quotemstr
Parent article: Evolving Git for the next decade

Looking at the friction of even using a bigger hash for git, I don't think Jujitsu is going to take over git's market share. There may be some minor UI benefits to using jj but I contend that the technical merits of jj vs git are marginal and subjective, and in some cases worse. People who don't like git usually just don't know it well enough.

to post comments

Jujutsu and Git

Posted Feb 13, 2026 22:01 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (6 responses)

A bigger hash requires global cooperation. Someone using jj locally requires nobody's permission, yes?

Jujutsu and Git

Posted Feb 13, 2026 22:29 UTC (Fri) by jc2026 (subscriber, #182142) [Link] (4 responses)

True, but using jj locally does not replace git in a true sense. I don't think jj is worth using locally either, even on a green field project. If you think git is hard, you just need to use it a bit more. Relatedly, I used to think git was weird and preferred other systems like Mercurial. But now I realize that was just a surface-level, naive analysis. Most of what git does is providing useful features and its complexity is exaggerated and all basically necessary. The actual concepts and format of git are simple. The features range from simple to sophisticated, and it is rare to be forced to use sophisticated features to just checkpoint or update your code. The command terminology and names are slightly strange, such as all the types of reset you can perform, but there are only a few so you can easily memorize them or make a cheat sheet. I think the model git uses, including its sharper edges, were thoughtfully added by people with experience using other tools and working on large codebases.

Jujutsu and Git

Posted Feb 13, 2026 22:42 UTC (Fri) by sunshowers (guest, #170655) [Link] (1 responses)

> But now I realize that was just a surface-level, naive analysis.

The lack of universal undo in Git is not a surface-level analysis. It is a fundamental limitation in essentially every pre-jj VCS. (No. the reflog is not universal undo.)

Having universal undo like in jj completely changes your level of confidence with source control operations. Screw up somehow? Make a bad edit? Simply run jj undo. People become experts much quicker when they can make mistakes and easily undo them.

Based on jj's experience I've started building an operation log and universal undo into basically any project where it's a good fit.

Jujutsu and Git

Posted Feb 14, 2026 4:28 UTC (Sat) by jc2026 (subscriber, #182142) [Link]

The "universal undo" of jj is achieved by removing some state concepts from git. That may be an improvement in some people's eyes but it makes certain commit history manipulations and constructions more difficult. I'm not the only person to think this. https://github.com/jj-vcs/jj/discussions/1905 I think git was built the way it is, as opposed to the way jj is, to solve a particular problem.

>Based on jj's experience I've started building an operation log and universal undo into basically any project where it's a good fit.

jj did not invent the concept of undo or anything. Different tools have different levels of sophistication in their staging and undo features. Vim for example has an undo tree. SQL databases have transactions. Git has the reflog and the ability to search and go back to any recent commit, tagged or not, and start over (outside of some bizarre circumstances that you must explicitly walk into).

Jujutsu and Git

Posted Feb 14, 2026 0:49 UTC (Sat) by marcH (subscriber, #57642) [Link] (1 responses)

> Most of what git does is providing useful features and its complexity is exaggerated and all basically necessary.

Try doing something like this with git: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and...

I tried to do more or less that with git for years. No matter what I tried, it was incredibly manual, slow and generally painful. Search "stacked diffs" and find a gazillion of git extensions/variants trying to achieve something similar. None of them does it with out-of-the-box git

Before jj, the least awful approach I eventually settled on was magit + linear branch + constant re-ordering.

I'm afraid you missed that quote in the article and more importantly _whom it came from_:

> "That moment when you realize that a tool simply fixes all the UI issues that you had and that you have been developing for the last 20 years was not exactly great."

Jujutsu and Git

Posted Feb 14, 2026 4:45 UTC (Sat) by jc2026 (subscriber, #182142) [Link]

You know, I skimmed that article and I don't see much of a point to working that way. I stack things up all the time and always rebase and reorder, and it's fine for the uncommon occasions when I have to do it. I prefer completely linear history too by the way. The only time it is ever actually a problem is when creating a PR on a branch with unrelated stuff outstanding, and I don't want to create a bunch of dependencies on things just because I happened to put them first in the commit sequence. For example, let's say I fixed a bug while adding a feature, but the feature commits are first. I have to either create a branch for the bug fix or else rotate the commit stack so that the bug fix one is first, so I can push it by itself. Then rotate again to update the other stuff. This is mainly necessary because the repos I work in are large and slow to manipulate and test. The ideal of making a new branch or new working copy doesn't make sense there.

I don't think it would be hard to solve this merge or stack problem in general. If you can figure out a way to correlate the commits, I'm sure ChatGPT can spit out a script to break this dependency thing easily. I never tried using a tool to solve this problem. Maybe Magit is what I should look for. But I'm not so bothered with my current methods either lol...

Jujutsu and Git

Posted Feb 15, 2026 2:08 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

I don't believe `jj` implements attributes, so projects using `eol=` or `text` attributes to force/modify default crlf/lf line-ending behavior may end up confused when edited with `jj`.