[cupofjoakim]

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue.

I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git cli hands down. I'm 100% on the path of least resistance when it comes to tool adoption.

[mamcx]

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.

I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands.

Now, I switched to `jj` a month ago and basically, I have learned around 60%-ish of it. And more importantly, I have gotten out of a bunch of serious trouble (you can UNDO!!!!) already.

But if this rant is not enough:

* You can UNDO. Everything. That is the major thing

* You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.

* The command made sense

* Nobody else knows you use `jj`, so no barrier to adoption.

* Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!

The major troubles:

* Not yet support for major tools, ides for it. It stays in `detached head` which is not as nice as showing the current branch on IDEs, and when you are fixing conflicts some tools do not get the diffs.

* No mature UI tool. I use `gg` which is fine enough

But the above is just temporal problems. Git will never be `fixed` or improved, so is pain forever.

[12_throw_away]

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.

Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a mess of wrong abstractions.

And unfortunately, these days I'm back using git with the rest of the world. Can't wait for the day when Jetbrains gets a good plugin for either `jj` or `sapling`, and I never have to google another git command again ...

[tripple6]

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed.

> You can UNDO. Everything. That is the major thing

Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean.

> You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.

It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

> The command made sense

It's nice.

> Nobody else knows you use `jj`, so no barrier to adoption.

It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS?

> Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!

I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

[eikenberry]

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git.

IMO Mercurial did a lot of this to themselves. I also preferred it at first but switched away from it due to their stance on no in-repo branching. They, of course, also lost due to git's author and network effects (github), but it wasn't all just "market forces".

[pkulak]

> Nobody else knows you use `jj`, so no barrier to adoption.

All my PRs now have branches named "push-kjasdfkhdf", so it's not terribly well hidden. :D

[saulrh]

The thing about jj is that it doesn't actually enable any new capabilities. I tell people to use emacs or vim or vscode or whatever instead of notepad because it gives them new capabilities, things that are simply unavailable unless you're talking to an LSP or running a full-powered scripting engine. jj doesn't make anything possible the way going from notepad to a real editor does. What jj does do is it makes everything so much easier that you can now actually use all of those features that git theoretically gave you. Rebases? No more fiddling, no more wedges, no more digging through the reflog because you fat-fingered something, you just go `jj rebase` and... that's it. And if you get it wrong, you just do `jj undo` and... that's it. And if you just had a six hour manic coding marathon without committing anything and now you want to spread its batch of changes back down through your patch stack, you just do `jj absorb` and... that's it. It's not the difference between notepad and emacs where you're going from no LSP to LSP, it's the difference between emacs@2016 where LSP support is a week-long adventure and emacs@2024 where LSP support is five lines copy-pasted out of the info page.

[sunshowers]

As a source control expert and jj's number one fan [1], I would count being able to defer merge conflict resolution as a new capability, FWIW. In general I think jj's greater than the sum of its (very good) parts because of how its features work together to create a coherent and pleasant user experience.

[1] the top testimonial on https://jj-vcs.github.io/jj/latest/testimonials/ is mine

[ehzy]

jj is not just a new interface for git, it has a lot of new and powerful features to offer, even when you're using the git backend with a colocated repo. Just to name a few:

- deferred conflict resolution

- The very expressive revset language

- the op log and ability to undo any operation

Many things that you can do with the git cli are significantly easier and in some cases comparatively effortless using jj. If all you do is git add and git commit then you probably aren't missing out on much, but if you ever split or rebase commits you should definitely try jj.

[dartos]

I switched from git to jj a few months ago, so I may have some insight.

I used it at work, where everyone used git, and there were 0 issues.

What I really like about it is how changes are sort of soft committed right away and, when I checkout a different branch or change, I don’t need to stash my changes and remember the stack of stashes.

Rebasing and merging feel a little easier, but that might just be because “ours” and “theirs” doesn’t get flipped during rebasing.

I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works)

All in all, it’s a solid, compatible, incremental step forward in VCS.

The only tangible downside for me is that it doesn’t support git hooks

[password4321]

> I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works)

Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?

[renox]

> The only tangible downside for me is that it doesn’t support git hooks

Thanks for this information: at work we use them for creating gerrit review id, so I'll wait until jj get this feature.

[cube2222]

So, I've felt pretty much like you - that is, I was happy with git, never really had major problems, and was generally content. Which meant that even though Jujutsu was on my radar for a while, it took me until now to take it for a spin.

In practice, for most bits and purposes, Jujutsu is just designed really well around a core set of primitives, which you use to achieve basically all your use-cases, which in git are spread across many fairly "special-case" features. This means that arbitrary "change tree modification" are pretty trivial.

The easiness of jumping into non-branch-tips and editing them with descendants automatically rebasing is also nice, to me, and fits in well with my workflow. Stacked PRs[0] are much less annoying than in Git thanks to auto-rebase as well.

Finally, I think the "Working on Two Things at the Same Time"[1] pattern is not easy (if even possible?) to achieve with git.

But all in all, as I wrote in the article's conclusion, the reason to use Jujutsu is that it just makes your VCS usage more pleasant, while generally not interfering with anything else as it effectively works as a git frontend.

[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

[1]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

[saghm]

I've switched over to using it pretty much exclusively over git directly. While there are a number of minor things that I prefer about it over git, these are the two main ones for me personally:

* If I don't pass `--allow-immutable`, trying to run a history-rewriting command will immediately fail if it would touch a commit that's present on a tracked branch from a remote. When using git directly, it's way easier to accidentally make changes during a rebase that conflict with remotes and then requires me to go back and fix it when I can't do a fast forward to sync the changes *Conflicts are part of the state of individual commits rather than a property of an ongoing operation. When an operation produces a conflict in one or more commits, I can still do whatever development (or make version control changes) on any of the other commits. I'm free to fix the conflicts in any order I want, or fix some of them now and worry about the others later, which is much more intuitive to me than using `rerere` to achieve something similar with git directly. I could even imagine a scenario where I might want to push up conflicts that come from attempting to merge my own changes with ones made in parallel from someone else so that they could resolve some of them if I wasn't confident in my understanding of the changes they made, although this isn't something that I've run into yet.

A lot of this hinges on the ways I personally use git; I tend to commit often and not worry about making sure the history is clean or the commit messages are perfect until I actually want to merge them, and I absolutely loathe merge commits, so this ends up meaning I rebase a _lot_. The benefits I mentioned probably wouldn't seem very significant if you don't work on shared codebases often or if you use git in a way that you rarely rebase, but because these feature solve concrete annoyances I'd run into quite often with git, the quality of life improvement feels massive to me.

[Hasu]

> when I can see something that beats the git cli hands down.

Then you should switch to jujutsu several months ago.

It's the biggest improvement to my development workflow in over a decade. The last change that was as big was git itself.

[zellyn]

I can second this opinion. The moment I read "something that beats the git cli hands down" I command-F searched for "hands down" to find this comment or make it myself.

[abound]

> I'm 100% on the path of least resistance when it comes to tool adoption.

Different folks will have different preferences when it comes to adopting new tools. Some like "tried and true", some want to experiment and see what's out there.

I (an avid `jj` user) like to think I want some pragmatic blend: I want tools that help me get my job done, and otherwise get out of the way. So if I think there's room for improvement in my workflows (in this case, managing 10-20 ongoing changes at a given time across 5-6 projects), I'll experiment with new tools that can help reduce the friction for me.

Like you said, there's functionally nothing `jj` can do that `git` can't, Jujutsu literally uses git as the default backend. For me, the power of Jujutsu is the massively reduced cognitive overhead of using it. My thoughts more directly translate to `jj` commands and I rarely have to think about it, even with complex stacks of changes.

[danpalmer]

It solves two problems. First is having a batter UI, git is well known to have a bad UI and be hard to teach. But you’re right there aren’t new capabilities.

Secondly, and more importantly, is that you can back it on to different storage mechanisms. Companies with large monotypes are often not using git (Google, Facebook,…), or are using highly specialised git (e.g. Microsoft). JJ is not just got compatible, git is a pluggable storage backend.

I mostly use JJ backing on to Piper, and the integration is excellent. I’ve also used it backing on to git. I can transfer almost all my knowledge and muscle memory between these two places.

[hellcow]

Stacked PRs with multi-branch rebases are effortless. Conflicts are actual things in the history that you can come back to later. Everything is automatically committed, so I don't lose work from a bad reset/stash pop.

Maybe these don't help you with your workflow. But in my case these solve the biggest problems I had with git while still being fully compatible.

[christophilus]

If you switch between branches a lot, it's a game changer. I look at it as just git with a sane CLI.

[oniony]

I personally switched over in December. For me it solves a few problem in an elegant way:

1. No branches. Instead of having tunnel vision on a single branch, you can easily hop around the tree, creating revisions and switching context without having to mess about stashing files and then remembering which branch and version each stash is for. The fact that your changes are automatically added to a revision make this very easy. You can literally drop what you're doing, `jj edit` or `jj new` a different commit to switch over to working on that stuff, whether it's on a Git branch or not.

For example, you could be working on a feature 'A', push your PR and then start work on feature 'B', only to find your pipeline has failed thereafter. You can then `jj new` a commit off your old feature commit, create a fix and push it (or even `jj squash` it first) and then `jj edit` back over to what you were doing on feature 'B' with no fiddly stashes.

2. Much simpler rebasing commands. For those of us who like to rewrite history to make PRs easier to comprehend for reviewers, and for general rebasing when your target branch has changes, I find the `jj rebase` much saner than Git. It's very easy to rebase a set of commits or move a single commit about in history.

`jj squash` is also great for fixing up earlier commits. You can `jj new` a commit off an existing commit, make a fix or change and then `jj squash` it into the previous one without a fiddly `git rebase -i HEAD~2`.

3. Automatically rebasing of descendents. If I edit a commit in the history, all of the descendents are automatically rebased with this change. So if I realise I've made a mistake in commit `aaa` and edit that commit, `bbb` and `ccc` that are derived from it will automatically incorporate this change, with commits being market conflicted if this can't be done.

4. Conflict handling. Any conflicts are recorded against commits and doesn't prevent operations from working. So you don't have to immediately drop everything and work interactively through a set of conflicts. Combine that with the automatic rebasing, above, and your resolutions propagate through the descendents similar to using git rerere.

So those, for me, are the killer features.

On the downsides:

1. HTTPS Git repository handling is poor. There is no vault integration, at least on Mac, so I have to enter my username and password every time. This is not a problem for SSH, but my company prohibits SSH, so it's a pain. ** see reply below, credential helper now works **

2. Git fetches seem slower for large changes than using Git fetch directly, and I've had the tool timeout on repositories with large files. Combined with the above issue I tend to now `git fetch` rather than ever `jj git fetch`, avoiding the two problems, and just push with `jj`.

Other than that I'm loving the tool.

[skitter]

> 1. HTTPS Git repository handling is poor. […] 2. Git fetches seem slower for large changes than using Git fetch directly

JJ used to use libgit2 for fetches, but it now can shell out to the git binary instead: https://github.com/jj-vcs/jj/pull/5228 (which will be the default in the future)

[cube2222]

> There is no vault integration, at least on Mac

I'm not sure when it was added, but now if you set `git config --global credential.helper osxkeychain` then it will work for jj, too.

[mixmastamyk]

Yes, so far these jj blog posts do not sell it well at all.

Not to mention the rainbow colors are a bit of a turnoff. I like a little color here and there, but not ransom-note style. Monochrome effects are available folks.

[stouset]

`jj --config ui.color=never`

Maybe the blog posts don't sell it well, but I find it pretty telling that bordering on zero people ever enter the comment section for Jujutsu posts to complain about a bad experience they had. Just dozens upon dozens of people singing its praises.

Think about literally other technology post on this site. Nothing is universally loved.

[theLiminator]

I think the main problem it solves is stacking https://www.stacking.dev/

[keybored]

That’s a problem created by GitHub or people unable to think outside of the GitHub model. It would make more sense to solve that problem through a review tool.

For what it’s worth from what I’ve read about JJ: it’s a better VCS frontend overall.

[sunshowers]

There is no substitute for trying it out for a few days. It will quickly become apparent why people like it so much.

[frizlab]

Well said.