[frizlab]

Yup. Still 0 incentive to try jj. I’m still very much convinced most of the problems solved by jj either do not exist or are already solved by recent features of git.

It’s good alternatives of popular tools exist but git would not be my first bet as a tool that needs fixing…

[magnio]

Why say yup to disagree with the premise of the article?

[do_not_redeem]

Some people just enjoy being contrarian.

I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.

[1718627440]

> Some people just enjoy being contrarian.

I have recently posted some critical questions. I didn't do that because I "enjoy being contrarian" (rather me enjoying a discussion). I did that to flesh out, what the benefits of JJ are. I think VCSs are interesting, I think Git has some issues, but in my opinion most problems are caused by a misguided mental models, I haven't/can't tried JJ. Most things I heard were workflows that are claimed are not possible in Git, but are possible and most-times only a few commands. There are other design choices which I disagree with and which might bother me.

("haven't/can't tried JJ" meaning I enjoy running a stable distro, but wouldn't mind compiling it myself. But Rust and Rust software is a fast moving target, so it is a hassle to deal with if you aren't invested in it's ecosystem. Also it violates the GNU standard, which makes it unfriendly for endusers, but this seams to be the norm nowadays.)

[nocman]

> Some people just enjoy being contrarian.

And some people just happen to disagree - doesn't automatically mean they just like "being contrarian". I took the "Yup..." to mean "this is what I was expecting, because it agrees with what I have seen before on this topic".

> I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.

And some unknown quantity of readers don't see anything compelling enough to either try it and/or comment on it after they have (or have not) tried it.

[frizlab]

Spot on to both.

[latexr]

> 0% tried it but decided not to switch.

It’s trivial to prove that’s not true. Just look at the last popular Jujutsu post on HN.

https://news.ycombinator.com/item?id=44643984

https://news.ycombinator.com/item?id=44643763

https://news.ycombinator.com/item?id=44646902

https://news.ycombinator.com/item?id=44645769

https://news.ycombinator.com/item?id=44662803

https://news.ycombinator.com/item?id=44644040

And those are just the replies to the top comment which matched “went back”.

[stouset]

To be fair, I more or less invited these responses by bringing it up. Organically, complaints are very rare.

Obviously not everyone who tries something is going to switch, even if you take as an axiom that the other thing is objectively better. But I still think it’s notable that—without explicitly prompting that type of response—so few people seem to have negative experiences with jj given how tribal and passionate engineers tend to be over tooling.

[IshKebab]

I dunno, I've tried it and I think I will stick with Git for a while longer at least. I really don't like the fact that it automatically commits changes in the working tree. Apparently you can turn it off but.. yeah I dunno.

I may change my mind. Especially if they provide a less shit alternative to submodules and LFS. (And I agree this guy is just being contrarian - jj definitely does fix some Git annoyances.)

[stouset]

This was the thing that stopped me from giving jj a shot for the longest time, but it turned out to be a complete non-issue. Definitely don't turn it off!

The "aha" moment you might be missing is that you should consider your latest revision to just be the staging area. `jj commit -i` (shorthand for `jj describe; jj split -i`) is effectively `git add -i; git commit`. If you're worried about accidentally pushing unfinished work, don't be! It won't let you push changes without a message by default, and you update bookmarks (e.g., branch pointers) at your discretion anyway. Both of these mean that `jj git push` isn't going to accidentally push a bunch of in-flight work.

Think of it less like jj commits everything by default, and more like your working copy gets the benefits of change tracking and being able to take part in repo operations even when you haven’t taken a moment to make a commit.

[IshKebab]

Say I check out a branch (or bookmark or whatever). I compile it. Some stuff doesn't work. I add some debug printfs. Compile it again. Ok I'm done now.

In git I can just revert all the changes and I haven't modified anything important. In `jj` won't I have actually added all of those debug printfs to the top commit of that branch? Now I have to manually revert the edit?

As I understand it, the answer is "aha, but you just have to remember to `jj new` before you do any edits. The problem is I'm very sure I will constantly forget to do that. I guess you could say Git is opt-in to modifying commits whereas jj is opt-out, and I think I prefer opt-in.

I have very little jj experience but does that sound accurate? (Genuine question; I would love something better than Git.)

[gpm]

The default command you should reach for with jj to checkout a branch is `jj new branch` which creates a new commit to store your debug prints. You shouldn't do a two step process where you can forget the second step in the first place.

That said, if you do for whatever reason run `jj edit branch` instead (which enables the case you are discussing), jj will have snapshotted the previous change so you can still automatically revert the debug prints using

   jj evolog; jj restore --from old_commit_id

[kinghajj]

In order to "check out a branch" in jj, you would have had to run `jj new` already. So your edits won't be "added ... to the top commit of that branch", but in a new commit (revision) when you checked out the branch. Then you can use `jj split` to keep whatever changes are important and discard the debug print statements.

[stouset]

In git you can also revert all the changes and you haven't modified anything important! `jj restore` or `jj abandon` would let you undo your changes or abandon the entire revision.

As others have noted, checking out a branch and accidentally modifying one of the commits on it is actually kind of hard to do. `jj git fetch` pulls in remote changes to your repo, but you don't "check out a branch": you either `jj edit` an existing commit or create a new one entirely with `jj new`. So you're unlikely to accidentally overwrite a commit by accident. I even find myself using `jj edit` less and less these days; if I want to change an existing commit (even if it's in the middle of a chain of commits), it's easy to `jj new <commit-to-modify>` and then `jj squash` the modifications into it. This allows me to double-check the modifications I'm making before I decide to commit to them (pun intended).

That said, I absolutely have forgotten to `jj new` before. Mostly this happens when I plop down at the laptop and start making changes without remembering to make a new revision. Whatever revision I happened to be on gets all those edits. Sometimes I work for quite awhile before realizing this, and so having to pick out which changes belong where piecemeal would be a ton of work.

But this is precisely the power of having all these changes in the repo as a revision. I can use all my SCM tooling to solve the problem for me! For the sake of this example, let's assume that I've pushed all my changes to a remote branch and then stupidly continued editing them. Now my local copy of branchname and branchname@origin have diverged; they both have the same revision, but different git contents.

    # Oh no! I've accidentally made edits to `master`. `omny` points to two
    # separate git commits; one is my local copy of `master` and one is the
    # remote.
    > jj log
    @  omny [e-mail] 2025-08-14 13:22:15 master* ae25
    │  Made some changes
    │ ◆  omny hidden [e-mail] 2022-03-26 14:49:58 master@origin 79d4
    ╭─╯  Made some changes
    ◆  notn [e-mail] 2022-03-23 17:03:05 b192
    │  Earlier changes

    # First, rebase our local changes onto the remote commit. This neatly
    # splits out the changes I just made from the changes that were there
    # before I messed up.
    > jj rebase --branch master --destination master@origin
    Rebased 1 commits to destination
    Working copy  (@) now at: omny?? 67a9 master* 
    Parent commit (@-)      : omny?? 79d4 master@origin

    # You can see that now my local changes have been rebased on top of
    # the remote copy. Unfortunately, they still have share the same
    # revision id so jj is not happy with me! We'll have to put those
    # changes into a new revision and make sure our local `master` points
    # to the same id as the one at `origin`.
    > jj log
    @  omny?? [e-mail] 2025-08-14 13:28:14 master* 67a9
    │  Made some changes
    ◆  omny?? [e-mail] 2022-03-26 14:49:58 master@origin 79d4
    │  Made some changes
    ~

    # Make a new revision for our changes to go into.
    > jj new
    Working copy  (@) now at: plwu 70d8 (empty)
    Parent commit (@-)      : omny 79d4 master

    # Abandon the local revision where we accidentally changed the 
    # `master` branch. Normally this would get rid of our changes,
    # but `--restore-descendants` makes sure that the filesystem
    # contents of the new revision we just made remain unchanged. 
    # Since we're getting rid of the revision that made those edits,
    # those edits have to be moved up into that new revision in order
    # for it to look the same as it did before!
    #
    # Abandon would also normally delete our local copy of the
    # `master` bookmark. But `--retain-bookmarks` keeps it, and pushes
    # it back one revision. This is exactly what we need!
    > jj abandon master --restore-descendants --retain-bookmarks
    Abandoned 1 commits:
      omny?? 67a9 master*
    Rebased 1 descendant commits (while preserving their content) onto parents of abandoned commits
    Working copy  (@) now at: plwu 69ce
    Parent commit (@-)      : omny 79d4 master

    # Everything is happy again! My recent changes are now on their
    # very own revision.
    > jj log
    @  plwu [e-mail] 2025-08-14 13:33:45 69ce
    │  (no description set)
    ◆  omny [e-mail] 2022-03-26 14:49:58 master 79d4
    │  Make some changes
    ~

I want to be clear about something here. I have never done this before. This isn't a pattern that's ingrained into me. I've certainly accidentally edited the wrong revision before, but it's always been relatively easy to split out the changes I made so I've never needed to really solve this in the general case before.

I read your comment, figured this would probably be the easiest way to do it using the primitives I'm familiar with, and I tried it. And it worked! I didn't need to go digging through manpages to figure out how to do it, it was a simple composition of commands I use every single day. I did this on a live, real repo I am actively working on where I had edits in flight, and just for giggles I squashed them into master. I had zero fear about doing this because a `jj op restore` would get me back to safety no matter what.

This will also work basically unmodified if you haven't pushed the changes. The only difference is you'd use the raw revision id instead of `master` and you'd use git commit ID of the earlier changes you wanted to keep (pulled from `jj evolog`), which you'd substitute everywhere I used `master@origin`. This works for every case where you have two sets of changes in one revision and you want to pull out the later changes from the earlier ones.

[homebrewer]

You're reading an extremely biased sample of experiences. It's probably the opposite: 90% haven't tried it, 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it. For an advanced git user, it doesn't offer all that much. I used it for a couple of weeks and can't say that it saved me any time or any amount of work; it was either zero, or so close to zero that I wasn't able to notice it.

When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.

[stouset]

> For an advanced git user, it doesn't offer all that much.

As a (former) advanced git user, nothing could be further from the truth. We are always the most passionate cohort of jj users in these threads. This is almost certainly because jj unlocks a bunch of additional abilities and workflows that we've been torturing out of git (or given up on, or didn't even conceive was possible) for years.

On the flip side if all you ever do it git pull, git commit, git push, jj is probably not going to offer you much.

[nixosbestos]

Wow, just wow.

>For an advanced git user, it doesn't offer all that much.

arrogant, and completely absurdly wrong. I've used Git for 20 years. `jj` the single best improvement to my development workflow in... well, since adopting Git.

> I used it for a couple of weeks and can't say that it saved me any time or any amount of work

I would bet 5 figures that's a lie.

> When Linus and his lieutenants switch over and recommend it as loudly as some do here, then I'll take another look. Very unlikely IMHO.

So despite all this chest puffing, an appeal to authority would tip the scales for you?

[stouset]

There’s no need to be antagonistic. We’re all friends here :)

I am an unabashed jj evangelist and I don’t think they’re lying when they say it didn’t save them any time. Adoption costs might be small but they’re not zero. Some workflows are easy with either tool. And some people just don’t “get” it and struggle to adapt to a different mental model. That’s okay!

> So despite all this chest puffing, an appeal to authority would tip the scales for you?

I think GP was simply saying this would be a clear sign to them that if it’s mature enough to handle kernel developers’ needs, that’s a good sign it’s worth the effort to switch. It definitely would be! I can’t wait to hear if and when kernel developers start switching; it will be a huge positive indicator.

[freeopinion]

So you're saying that novice jj users don't get any more benefits than they would if they made an effort to be an advanced git user?

[gpm]

> 90% haven't tried it,

This is almost certainly true.

> 9% tried and didn't see any reason to switch, and around 1% have switched and won't shut up about it

This is almost certainly not true. People are far more inclined to give negative reviews than positive reviews.

[totallykvothe]

I tried it and decided not to switch because there was simply no way to resolve the line endings problem on Windows and sync up jj with our git repo

[steveklabnik]

The line ending thing should have been resolved very recently, I believe: https://github.com/jj-vcs/jj/pull/6728

[rootnod3]

I mean, undo alone is a killer JJ feature. Sure, you can always somehow undo any git operation if you dig deep enough, but the ease of use on the JJ side without question.

[stouset]

The oplog is absolutely amazing. Having such a comprehensive safety net means you can have absolutely zero fear from doing absolutely anything to your repo, because you can always return the repo itself back to a known-good state. It's git's reflog on steroids.

[rootnod3]

Exactly. Even if outside of all that JJ would be an exact Git copy...undo alone is worth using it.

[mrbonner]

“You miss 100% of the shots you didn’t take” - Michael Scott.