I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review?
I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC.
But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.
> do I get any benefit from the change id if I push to GitHub for PR review?
As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure.
However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see!
> But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in.
It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.
I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)
- Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ...
- CLI first
- Offline first (+ syncing)
- A website for hosting/presentation
Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.
> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size.
I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?
So excited for this. I talked to the ERSC folks last year about joining but it was a little early for me. Still incredibly excited about what they're building and glad to see one of my favorite people joining the effort.
I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the same time). So something like what this author is working on is needed.
One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.
This is an interesting idea... jj has a templating language, but it's not stateful, so you couldn't like, hide some commits based on other commits, for example. But I'll file this away...
I guess I see what the author was trying to convey talking about Rust/Go at the start but I'll admit it confused the hell out of me when we got to Jj (horrible name IMHO but whatever).
Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go).
Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least).
I hope this helps someone else who might be confused like I was.
Thank you for the feedback! I talk about it so much I feel like regular readers of my blog will know this stuff already, but I also don't want to leave out important context for others.
The full name is Jujutsu, but I think "jj" did come first. "j" is nice because on QWERTY keyboards, not only is it on the home row, it is one of the two keys that has a little tactile marker (bump) on it.
Since JJ has technically git compat, I think there's 2 things needed for it to take off
1. A good vscode extension (there's two so-so ones that I'm not sure are being updated)
2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs
I do think that GUI stuff is important, there's a lot of folks who have said "not interested unless there's a magit equivalent" which I totally understand. I'm not a big GUI person for VCS myself, so I don't feel the same pain.
For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll have to experiment with it myself.
What a terrible world we're barrelling towards when "LLMs don't know about it" is considered a blocker towards something taking off. Read a blog post, read a man page (which GP says was indeed their solution), or just play with the dang tool, I assure you these things are still possible without the assistance of a predictive text engine helping you!
One problem is that Stack Overflow isn’t being updated with questions about new tools because it’s been crowded out by LLMs, so the LLMs can’t train on these nonexistent new questions/answers.
> I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first.
Using VC commands an LLM generates for you sounds like a pretty terrible idea anyway. What if they delete your data? Why not spend 5 minutes searching for information written by a human?
At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted.
I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think.
Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.
I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use.
The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move.
I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
Sure, definitely, sorry for being a bit off-topic, clearly this was about you and your plans and not intended to be about jj itself.
Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX.
And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.
So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git.
What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git.
I loved git. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.
As someone who loves git, has always thought the criticisms about its interface were overstated... but also feels like it maybe has too many incoherent ways of doing things, this is the best sales pitch I could've asked for (and I came to the comments to ask for a sales pitch). Thanks - I'll try jj out the next time I start a hobby project.
Another good sales pitch is `jj undo`[0]. It puts the repo back to previous state, regardless of what the mutative operation was. It's a powerful and simple safety net that unlocks experimentation.
It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.
jj undo is great but it's a one time thing. You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT. You have to look into the op log and jj op restore for that. It's nice you can get back to where you were though.
The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I know there are similar cases in git but I guess I'm just used to git so I wasn't using those cases.
that said, I'm mostly enjoying jj. Though quite often i get a conflict I don't understand. Today I got 2 and it told me choose A or B. I did `jj diff -r A -r B` and it said no diffs. If no diffs aren't there no conflicts? I'm sure someone gets it but it was annoying to just have to pick one to abandon
You're welcome, and feel free to let me know how it goes. There is an adjustment period, for sure, and (in another eerie parallel to Rust) some folks try it, bounce off, and try again later, and it sticks then.
The auto-commit behavior was one of my biggest concerns when starting, but it turns out that when combined with other things, I'm a huge fan now, for example.
Right, “parent branch” implies a tree structure, but git is a DAG.
You might have a specific workflow such that you can actually answer your question, but it won’t generally apply to all repos.
Since a branch is really just a label for a specific commit, which may be at the end of a chain of successive parent commits, a branch isn’t really a first class structure, but a derived one.
You can get the fork point of a branch, which is a common ancestor commit shared by another branch, but that fork point is a commit and may not have a branch label. That commit can have any number of other branches going off of it: how would you decide which one is the parent vs just another sibling?
My assumption after looking at jj is that it is not as complicated as git yet. Give it time. It’s also not even as simple as git for many tasks, based on their own docs: https://jj-vcs.github.io/jj/latest/git-command-table/
I don’t think you ever need to do this, jj tracks changes much better than git, assuming I understand your question. E.g. you can rebase a whole local change dag based on a commit from origin with a single jj rebase -b and it’ll move bookmarks (git branches) correctly.
It's technically a bit more than that. JJ is its own VCS, with pluggable backends. Google has a closed-source Piper backend, the git backend is the only real open source backend. But at high level, it's fine to think about it in that way, yeah. I tend to think about it as being more "able to work on git repos" than as a UI.
Git's CLI is awful compared to fossil or even mercurial. Jj seems like an improvement over git, but it lacks a web UI like fossil has. It's very useful. Basically like a self contained github lite, only without the needless complexity, the enterprise bs, the annoying login process, tokens, passkeys, brain damaged permissions system etc.
I used to think the same way about jj not too long ago. I even wrote a few comments here similar to yours, but since then I’ve changed my mind.
For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back
In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
Basically the same except in some projects we are not supposed to squash. So, sometimes we end up with long long histories to be rebased onto other long histories.
rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.
jj is actually so good though. People don't need to know you're using it, which is why it's nice.
A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts.
I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane.
To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away.
Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
I use git but I instead just keep all PRs stacked on top of each other and rebase when one is merged. If something is easy to review I push it down the stack. If something is harder to review I keep it at the top of the stack.
I don't open a PR for each commit, and we use squash commits at work which makes it harder to have this workflow but it still works fine for me.
I rebase only the leaf PR, and I have update-ref enabled to update the branch refs of all other branches in the stack. It works well. The only manual process is that I have to manually force push each branch afterwards.
Lastly, I use the `-x "cargo fmt" -x "cargo clippy"` feature when rebasing (which is missing in jj) to make sure the stack stays in a good state
I have a question and you might have an idea about this:
I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do.
I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually.
Do I understand correctly that jj does it automatically?
I've also worked with CSV (barely) and SVN (more extensively) and I was blown away by Git.
You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on.
There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
I think yours a perfectly reasonable stance, and I often feel the same way. And all this complaining about git is getting tiresome, especially if you had to deal with its predecessors.
FWIW, I still tried out jj and found it a joy to use. I use it all the time now. Most of the time, it not only gets out of your way, but rolls out the red carpet. I'm saying that as someone who knows their way around the git command line. t's like replacing your trusty old remote control with a new one where the buttons are well labeled, ergonomically placed, that lets you do entirely new useful things, and it has a universal back button that just works.
Maybe jj is an especially good fit for my way of working, but I do think that it is a real, actual improvement for everyone.
And it's super easy to pick up anytime. So yeah, I think you're doing it right! Sit back and let it come your way. From what I can see, there's a pretty good chance that it will.
The good thing is that a new player entering the arena allows a fresh look at certain problems, and some solutions then get backported to the OG project. I've read it already happened that jj inspired some changes in git.
Same happened e.g. with nodejs getting deno and bun around, which allowed to break nodejs' inertia on many problems that the others have solved.
I learned all of cvs, svn and then later git when getting into Linux and Open Source. Based on my early experience of multiple systems, I'm very surprised that git has dominated and lasted this long already!
I used to think this, too. Tried jj a few times before it clicked.
It’s very liberating in some ways, in others it’s simply no worse than git. You can do everything you can do with git, but some of those things don’t require multiple steps or n repeats of the same action. jj rebase + commitable conflicts + jj undo = freedom and peace of mind.
Fair points. I'm also generally happy with Git myself.
I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits).
Stacked PRs also look interesting but I haven't had an occasion to try them out yet.
I think that the ability to collocate with fit is really the thing that makes even evaluating the use of jj feasible in many organizations. To consider pijul, it requires throwing away all of your forge setup, configuration, permissions, backup, disaster recovery, as well as updating every CI pipeline.
In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
I'll be honest, I did too. No https cert makes it give a warning in Chrome, which I had expected to just be a 404, and was surprised when it actually worked!
If JJ takes off it won't be for any technical or logical reason. It will be because the world of internet programmer media (hn, x, youtube, reddit, mastodon, lobsters) will be saturated with JJ tutorial edutainment targeted at people who need AI to vibecode HTML / CSS.
There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact. I wish the people who will decide to dedicate the precious few years of their life to JJ the absolute best but I hope that they decide to do so only after understanding and fully digesting the aforementioned perspective.
My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.), focus on something whose main appeal is more than social, i.e. "This would be so great if everyone used it!" Otherwise you're just working on a popularity contest. Remember this comment.
> There are no substantial technical or usability reasons to switch to JJ from Git [...]. This is a neutral impersonal opinion that is virtually a fact.
> it's impractical for most working programmers to switch
I don't know what you mean here. I think it's quite practical to switch to jj, and people switch over all the time. Some people are going to be earlier adopters than others, but the early adopters can bring others along (as I've been lucky to do at Oxide).
> focus on something whose main appeal is more than social
Steve and I both think that Jujutsu's appeal is far more than merely some bandwagon effect. I do think that social appeal is an important part of making a project succeed, and that projects without substantial technical merit win due to social appeal all the time, but Jujutsu has both! It's amazing!
> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact.
Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
> it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.
Changesets, the op log, first class conflicts, no staging area.
JJ might produce commits that can be stored in Git, but the affordances are different. If Git wants to adopt them, it becomes no longer Git.
On the other hand, I'm happily using JJ while everyone I collaborate with is using Git. JJ doesn't need to "win" to be useful, it just needs to be useful enough that the people who maintain it continue to maintain it.
> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch.
Not in my experience. jj is easy to pick up and a joy to use. I like git. I deeply appreciate git. But git can feel like snow shoveling sometimes, while in jj things just click into place.
jj is freeing, because things that were a hassle before are now easy, and other things that were impossible are also easy.
I know there's a lot of hype around for a lot of things, and I get grumpy from all of it. Jujutsu is one of the few things that actually deserve the praise being heaped on them.
You may disagree, of course. But I hope that some day, you'll have reason to be happy about this tool, instead of feeling... whatever touched you off like this.
This comment could have been written when people were pushing to SVN repos on SourceForge when Git was becoming the next big thing, enough for a competitor to founded.
Yet still, the status quo is not Subversion and SourceForge, both of which have been relegated to antiquity, but git and GitHub.
Will something else unseat git and GitHub in the coming years? And will it be Jujutsu or some other innovation on version control?
Who knows, but I see no need to be so dismissive of somebody’s passion in such an arrogant way.
> There are no substantial technical or usability reasons to switch to JJ from Git
Every magit user disagrees with you.
> and it's impractical for most working programmers to switch
This very much sounds like someone who has never even tried jj. Tell us: What makes switching impractical?
> My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.),
I was thinking, it'll probably catch on like Omarchy did, except it's written in Rust, so... little chance of it being milkshake-ducked.
But as we say on Hackernews, there are two kinds of people with respect to jj: those who love it, and those who haven't tried it.
Doing the same thing, but with better usability, is immensely valuable. Remember, Hackernews thought Dropbox was "just" ssh+rsync, but they made a billion dollars making that easy.
I’ve tried it. I don’t love it or hate it. It’s more of a “meh”. I can see how it’d be nice if I was disciplined about my commit history, but I tend to be fine with chunky, clunky git. I don’t spend as much time curating perfect commit history as jj fans seem to.
I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC.
But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.
> do I get any benefit from the change id if I push to GitHub for PR review?
As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure.
However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see!
> But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in.
It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.
https://ersc.io/
- Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?
But yeah, it's been a lot. Frankly even harder to keep track of from the outside!
Steve, if you come to NYC hit me up!
Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go).
Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least).
I hope this helps someone else who might be confused like I was.
I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs
For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll have to experiment with it myself.
Give it time. Once JJ resources enter the dragnet of future model datasets, LLMs will get better at regurgitating it.
Using VC commands an LLM generates for you sounds like a pretty terrible idea anyway. What if they delete your data? Why not spend 5 minutes searching for information written by a human?
I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think.
Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.
The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move.
I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX.
And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.
What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git.
I loved git. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.
It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.
0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-undo
1: https://jj-vcs.github.io/jj/latest/operation-log/
The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I know there are similar cases in git but I guess I'm just used to git so I wasn't using those cases.
that said, I'm mostly enjoying jj. Though quite often i get a conflict I don't understand. Today I got 2 and it told me choose A or B. I did `jj diff -r A -r B` and it said no diffs. If no diffs aren't there no conflicts? I'm sure someone gets it but it was annoying to just have to pick one to abandon
The auto-commit behavior was one of my biggest concerns when starting, but it turns out that when combined with other things, I'm a huge fan now, for example.
This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."
You might have a specific workflow such that you can actually answer your question, but it won’t generally apply to all repos.
Since a branch is really just a label for a specific commit, which may be at the end of a chain of successive parent commits, a branch isn’t really a first class structure, but a derived one.
You can get the fork point of a branch, which is a common ancestor commit shared by another branch, but that fork point is a commit and may not have a branch label. That commit can have any number of other branches going off of it: how would you decide which one is the parent vs just another sibling?
My assumption after looking at jj is that it is not as complicated as git yet. Give it time. It’s also not even as simple as git for many tasks, based on their own docs: https://jj-vcs.github.io/jj/latest/git-command-table/
Makes sense. Developers I know have been wanting that.
https://www.gameoftrees.org/
For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back
In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.
A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts.
I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane.
To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away.
Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
I don't open a PR for each commit, and we use squash commits at work which makes it harder to have this workflow but it still works fine for me.
I rebase only the leaf PR, and I have update-ref enabled to update the branch refs of all other branches in the stack. It works well. The only manual process is that I have to manually force push each branch afterwards.
Lastly, I use the `-x "cargo fmt" -x "cargo clippy"` feature when rebasing (which is missing in jj) to make sure the stack stays in a good state
I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do.
I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually.
Do I understand correctly that jj does it automatically?
You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on.
There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
Hot take, but I personally hate git and almost always rely on a GUI tool or IDE integration to interact with it.
FWIW, I still tried out jj and found it a joy to use. I use it all the time now. Most of the time, it not only gets out of your way, but rolls out the red carpet. I'm saying that as someone who knows their way around the git command line. t's like replacing your trusty old remote control with a new one where the buttons are well labeled, ergonomically placed, that lets you do entirely new useful things, and it has a universal back button that just works.
Maybe jj is an especially good fit for my way of working, but I do think that it is a real, actual improvement for everyone.
And it's super easy to pick up anytime. So yeah, I think you're doing it right! Sit back and let it come your way. From what I can see, there's a pretty good chance that it will.
Same happened e.g. with nodejs getting deno and bun around, which allowed to break nodejs' inertia on many problems that the others have solved.
It’s very liberating in some ways, in others it’s simply no worse than git. You can do everything you can do with git, but some of those things don’t require multiple steps or n repeats of the same action. jj rebase + commitable conflicts + jj undo = freedom and peace of mind.
I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits).
Stacked PRs also look interesting but I haven't had an occasion to try them out yet.
In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact. I wish the people who will decide to dedicate the precious few years of their life to JJ the absolute best but I hope that they decide to do so only after understanding and fully digesting the aforementioned perspective.
My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.), focus on something whose main appeal is more than social, i.e. "This would be so great if everyone used it!" Otherwise you're just working on a popularity contest. Remember this comment.
I respect your opinion, but I don't think it's a fact and I couldn't disagree any further with it. I wrote a whole testimonial about why I love jj (first one there): https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...
> it's impractical for most working programmers to switch
I don't know what you mean here. I think it's quite practical to switch to jj, and people switch over all the time. Some people are going to be earlier adopters than others, but the early adopters can bring others along (as I've been lucky to do at Oxide).
> focus on something whose main appeal is more than social
Steve and I both think that Jujutsu's appeal is far more than merely some bandwagon effect. I do think that social appeal is an important part of making a project succeed, and that projects without substantial technical merit win due to social appeal all the time, but Jujutsu has both! It's amazing!
Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.
Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.
JJ might produce commits that can be stored in Git, but the affordances are different. If Git wants to adopt them, it becomes no longer Git.
On the other hand, I'm happily using JJ while everyone I collaborate with is using Git. JJ doesn't need to "win" to be useful, it just needs to be useful enough that the people who maintain it continue to maintain it.
sounds like someone hasn't used jujutsu
Not in my experience. jj is easy to pick up and a joy to use. I like git. I deeply appreciate git. But git can feel like snow shoveling sometimes, while in jj things just click into place.
jj is freeing, because things that were a hassle before are now easy, and other things that were impossible are also easy.
I know there's a lot of hype around for a lot of things, and I get grumpy from all of it. Jujutsu is one of the few things that actually deserve the praise being heaped on them.
You may disagree, of course. But I hope that some day, you'll have reason to be happy about this tool, instead of feeling... whatever touched you off like this.
Yet still, the status quo is not Subversion and SourceForge, both of which have been relegated to antiquity, but git and GitHub.
Will something else unseat git and GitHub in the coming years? And will it be Jujutsu or some other innovation on version control?
Who knows, but I see no need to be so dismissive of somebody’s passion in such an arrogant way.
Every magit user disagrees with you.
> and it's impractical for most working programmers to switch
This very much sounds like someone who has never even tried jj. Tell us: What makes switching impractical?
> My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.),
Is Steve even a developer for jj?
I am assuming that this new job will change that.
But as we say on Hackernews, there are two kinds of people with respect to jj: those who love it, and those who haven't tried it.
Doing the same thing, but with better usability, is immensely valuable. Remember, Hackernews thought Dropbox was "just" ssh+rsync, but they made a billion dollars making that easy.