stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?
I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.
I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros.
I’ve never used magit but I used GitUp (https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...
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 :)
If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.
- 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 use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
When I tried Fossil it had things weirdly separated.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.
> 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?
I hope it sticks around so that I can use the same workflow at work and home. I'm really enjoying how fast all the jj operations are compared to mercurial.
The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.
Why did Google decide to choose Mercurial? Based on what I read the main reason was that the mercurial dev team was willing to prioritize features needed for Google to add custom extensions to support its monorepo, and the git dev team wasn't going to reprioritize just for the sake of Google.
Yes, that's correct. Another reason was that Mercurial is easier to customize because it's written in Python so we could sometimes just replace whatever we needed without needing much changes from Mercurial itself.
Yet another reason is that the .git directory is considered a documented API and several other tools and libraries depend on it (e.g. JGit and libgit2). So any new features for Google would need to be made to those tools too if we wanted things built on them to work.
I can second that the aforementioned reasons are true. The funny difference is that Google employs the primary git maintainer. Git has a lot of customers though so it rightfully is very conservative with development.
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.
Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king...
git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).
What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.
From the user's perspective, when setup correctly Git LFS is transparent and they don't see the text pointers - the binary files are replaced on push and pull to the server.
It's the same user experience as Perforce?
Yes, Git is more low-level and it's possible to see those text pointers if you want to.
I am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC.
Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
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.
That line wasn’t even in the original post. It is not nearly the only technical advantage. The point of the post is just not about that topic, so that content is not in the post.
This is very funny. People just love jj! There are no conflicts of interest, at least not until now that there is a company built around jj. But they also started it because they love jj!
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...
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 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 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?
I'm not running them blindly and I do always ask the llm to explain the command since the end goal is not to have the llm do the work but rather for me to learn jj.
+ any good tool will not let you run destructive commands without confirmation unless it's with some force flag and I have enough computer knowledge to not use force flags blindly.
+ "information written by a human" can be unreliable too.
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 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.
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 strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.
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 can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT
You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).
> 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'm not 100% clear on what you mean here, but a few things that might help:
1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).
2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.
3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.
4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.
I’m not sure if it’s a typo, but you don’t need to edit and then new, you can just new. It’s a good habit to get into as a replacement for checking something out.
I’m not sure what happened in your conflict situation either, that does sound frustrating. EDIT: Oh, I wonder if it was this: https://jj-vcs.github.io/jj/latest/technical/concurrency/ specifically, that I bet the repo was being modified concurrently, and so you ended up with a divergent change.
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.
Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both.
If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)
That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).
For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).
It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.
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.
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.
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.
> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden.
That's definitely something that could be better for me. (That said, there are other projects making it better too.)
Without knowing much about jj, isn't this more of a problem in how the GitHub/GitLab/Forgejo Pull Request system works rather than a jj problem?
Patch-based workflows in general (where you heavily use git rebase -i to curate a smaller set of "perfect" commits for anything you'd PR, rather than just piling new commits onto every PR) don't work well with the GitHub approach, which heavily favors merging stuff through the web interface (making merge or squash commits along the way).
You can make it work of course, but GitHub tends to behave in weird ways when it comes to how it's interface works with patch-based workflows. Perhaps a better estimate would be to see how it compares to a forge like Phorge or Sourcehut.
Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.
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?
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 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.
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?
One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
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!
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 personally feel quite capable at git and am not looking for another flow or tool.
But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history.
(I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.)
I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.
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!
Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.
There hasn’t been a ton of desire for it because it’s easy to just run git format-patch. Jj’s workflows feel closer to the email workflow than not, but prioritization in a young project is tough.
What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a large refactoring or other big change, then that was work best done on a weekend because branching and merging didn’t work very well.
Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.
This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results.
I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.
> 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!
Perhaps take a look at jj and give it a go. Maybe you’ll like it.
I know I did. The fact I can use it with git and it doesn’t interfere with any GitHub PR workflows means no-one needs to know I use it. I enjoy the jj model. Maybe you could too, and it’s not a crazy investment of time and energy. It’s an evening playing around with a code kata or something.
Then working with vcs becomes that little bit more enjoyable.
> 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.
These are my thoughts exactly. Focus on building the best thing instead of telling everyone about the dreams you want to reach. Speak softly and carry a big stick as it were.
> 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.
stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?
I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.
I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros.
I’ve never used magit but I used GitUp (https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...
Oh wow, they were going for "magic" with that name?? I read it as "maggot".
I think the real news is that some people have started to build what might become something like a "jjhub".
https://ersc.io/
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 :)
If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.
What I would love:
- 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 use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
So you want Fossil?
When I tried Fossil it had things weirdly separated.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
except fossil decided to never allow changing history, vs jj which makes history rewriting so much easier
I would love having some first class support for monorepos at bigger organizations (ex: silos, vfs, etc).
No promises but noted for sure…
There’s this as well: https://blog.tangled.org/stacking
Gerrit also maps really nicely to jj concepts, and there is an accepted RfC to add support for Jujutsu change IDs to Gerrit.
This is a great thing and I'm hoping for its success. It's about time we have a real alternative to Github.
Another reason to leave GitHub and their weekly downtime!
That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.
Say what you will -- East River Source Control is a great name
> 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?
I hope it sticks around so that I can use the same workflow at work and home. I'm really enjoying how fast all the jj operations are compared to mercurial.
I don't think this is quite right.
The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.
What was the reason for using Mercurial?
Why did Google decide to choose Mercurial? Based on what I read the main reason was that the mercurial dev team was willing to prioritize features needed for Google to add custom extensions to support its monorepo, and the git dev team wasn't going to reprioritize just for the sake of Google.
Yes, that's correct. Another reason was that Mercurial is easier to customize because it's written in Python so we could sometimes just replace whatever we needed without needing much changes from Mercurial itself.
Yet another reason is that the .git directory is considered a documented API and several other tools and libraries depend on it (e.g. JGit and libgit2). So any new features for Google would need to be made to those tools too if we wanted things built on them to work.
We also consider Mercurial to have better UX.
I think you’re confusing Google with Facebook.
j2kun seems to be a googler so I don't think so, but it's true that Facebook also went with Mercurial. I suspect it was for similar reasons.
Ahh. It sounded like a repeat of https://graphite.dev/blog/why-facebook-doesnt-use-git but maybe it did happen for both companies! They’d obviously be having similar issues. Thanks :)
I can second that the aforementioned reasons are true. The funny difference is that Google employs the primary git maintainer. Git has a lot of customers though so it rightfully is very conservative with development.
The intention with this is to also deprecate the Perforce fork, in my understanding.
But yeah, it's been a lot. Frankly even harder to keep track of from the outside!
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.
Glad to hear you enjoyed it :)
> 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.
Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).
Perforce’s binary support is basically equivalent to Git LFS, it does the same thing.
What does Perforce binary support have that Git LFS doesn’t?
AFAIK, the base issue that Perforce is already in use and it has enterprise support.
What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.
From the user's perspective, when setup correctly Git LFS is transparent and they don't see the text pointers - the binary files are replaced on push and pull to the server.
It's the same user experience as Perforce?
Yes, Git is more low-level and it's possible to see those text pointers if you want to.
I am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC.
Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
1. Perforce checkout requests always do the round trip to the server.
2. Artists can actually understand Perforce.
It uses Git for storage and does not support LFS, so it's as bad as Git used to be for this specific usecase.
LFS sorta kinda works in my understanding, it’s not super nice yet though.
Right now, nothing special. But this is very much an area that's known about and something may happen in this area, we'll see.
If you could elegantly handle large or frequently-changing binaries I think I'd be willing to switch immediately.
It has always annoyed me that there's not any clever way to handle binary changes with version control.
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.
Yeah, sapling and jj are fellow travelers, for sure :)
I'm kind of ambivalent about jujutsu. There's too big of an impedance mismatch between GitHub PRs and jujutsu, nor does it have a good VS Code UI.
I only use it when I have a ton of minor PRs I want to work on simultaneously, otherwise I just do git worktrees.
I'm mainly in favour because my name is JJ and sharing my name with a widely-used source control tool might help my career.
For all its warts and less than stellar UX Git is good enough (from a former Mercurial user)
After reading the article, the technical merits of `jj` are completely unclear.
Yes, that was not the goal of the post. There's some comments about this in this thread though, here's the first one of mine: https://news.ycombinator.com/item?id=45673808
That URL https://news.ycombinator.com/user?id=steveklabnik is a link to your user profile.
Whoops, managed to fix it. Thank you!
[flagged]
That line wasn’t even in the original post. It is not nearly the only technical advantage. The point of the post is just not about that topic, so that content is not in the post.
That line _is_ in the post. Search for it. I'm not sure what you're on about.
Wasn’t in the original post. I added it based on feedback in this thread.
[flagged]
This is very funny. People just love jj! There are no conflicts of interest, at least not until now that there is a company built around jj. But they also started it because they love jj!
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've thought that it could be as simple as commit's with a message beginning with "minor:: " do not get shown by default.
Hmm, yeah that might work. I was thinking about grouping all “minor::” commits as one commit, but this sounds more feasible.
You could probably use bookmarks for this.
jj describe -m "Good luck, Steve!"
Thanks!
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.
Steve, if you come to NYC hit me up!
Thank you! I’ll try to remember that.
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.
I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
If you're asked why Rust. I believe you are always free to choose.
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 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?
I'm not running them blindly and I do always ask the llm to explain the command since the end goal is not to have the llm do the work but rather for me to learn jj.
+ any good tool will not let you run destructive commands without confirmation unless it's with some force flag and I have enough computer knowledge to not use force flags blindly.
+ "information written by a human" can be unreliable too.
jj undo :)
You're kind of right about LLM knowledge but the implication is funny. We just cant be expected to learn new things without LLMs...
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 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.
Since they guy behind it works at Google, I wonder if gemini is better at it.
I don't think Google is best though of as a singular entity, I'd very seriously doubt that if it is, it's because of this.
Doubt the gemini team handpicks training material based on wether the author works at google or not. Doubt they handpick it at all.
Both Claude and Gemini can be integrated reasonably by informing them how to use JJ commands or even through MCP
> LLM knowledge
Give it time. Once JJ resources enter the dragnet of future model datasets, LLMs will get better at regurgitating it.
Is there a jj tutorial not assuming git knowledge at all? I'd love to see how to approach jj without git.
Someone attempted that a couple of months ago: https://jj-for-everyone.github.io/
Discussion: https://news.ycombinator.com/item?id=45083952
Not really, but I think there should be.
I think jj is great, godspeed!
Congratulations on the new adventure, Steve, and good luck!
I’m just sad pijul doesn’t get the same attention or love from the community. It desperately needs an ability to colocate with git.
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 strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.
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.
One thing not mentioned in the article: what advantages does jj offer over plain git?
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.
0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-undo
1: https://jj-vcs.github.io/jj/latest/operation-log/
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
> jj undo is great but it's a one time thing.
For what it's worth, this changed in v0.33.0:
> jj undo is now sequential: invoking it multiple times in sequence repeatedly undoes actions in the operation log.
(release notes: https://github.com/jj-vcs/jj/releases/tag/v0.33.0)
> You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT
You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).
> 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'm not 100% clear on what you mean here, but a few things that might help:
1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).
2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.
3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.
4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.
0: https://github.com/jj-vcs/jj/blob/main/CHANGELOG.md#0330---2...
1: https://social.jvns.ca/@b0rk/111709462585184810
I’m not sure if it’s a typo, but you don’t need to edit and then new, you can just new. It’s a good habit to get into as a replacement for checking something out.
I’m not sure what happened in your conflict situation either, that does sound frustrating. EDIT: Oh, I wonder if it was this: https://jj-vcs.github.io/jj/latest/technical/concurrency/ specifically, that I bet the repo was being modified concurrently, and so you ended up with a divergent change.
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.
Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both.
If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)
That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).
Yeah, in that case you may want to configure bookmarks to auto update for sure :)
Is there a way to do that today?
For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).
It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.
can you directly get the parent branch of a branch in jj?
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."
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.
Could you spell out slightly more what you mean? I'm not 100% sure what "get" means.
I think they mean what other branch some branch was originally branched off from.
So better UX while keeping git's solid internals?
Makes sense. Developers I know have been wanting that.
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.
I can't hear Piper backend without thinking about Pied Piper
Not the only project that's working on that.
https://www.gameoftrees.org/
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
May I ask what is your rebase workflow at work?
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.
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.
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.
> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden.
That's definitely something that could be better for me. (That said, there are other projects making it better too.)
Without knowing much about jj, isn't this more of a problem in how the GitHub/GitLab/Forgejo Pull Request system works rather than a jj problem?
Patch-based workflows in general (where you heavily use git rebase -i to curate a smaller set of "perfect" commits for anything you'd PR, rather than just piling new commits onto every PR) don't work well with the GitHub approach, which heavily favors merging stuff through the web interface (making merge or squash commits along the way).
You can make it work of course, but GitHub tends to behave in weird ways when it comes to how it's interface works with patch-based workflows. Perhaps a better estimate would be to see how it compares to a forge like Phorge or Sourcehut.
Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.
I'm banned from force-pushing at work so this makes jujutsu a challenge for me.
The workflow still functions, it just requires me to manually update bookmarks.
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 believe `jj fix` is your -x equivalent, though im not familiar enough with it to comment on how similar the semantics actually are
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?
That's correct, it will do the cascade rebase of everything automatically.
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 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.
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?
One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
Ergonomics are everything. Its why there are zillion IDEs, terminal apps, keyboards, mice, etc.
Hot take, but I personally hate git and almost always rely on a GUI tool or IDE integration to interact with it.
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!
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 personally feel quite capable at git and am not looking for another flow or tool.
But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history.
(I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.)
I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.
Off-topic: I found it very surprising the Logical Awesome website still works.
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!
Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.
There hasn’t been a ton of desire for it because it’s easy to just run git format-patch. Jj’s workflows feel closer to the email workflow than not, but prioritization in a young project is tough.
Steve, Rain, please call it dojo.dev or something before jjhub catches on.
Rain’s not working at ERSC, but we won’t be naming the product jjhub, don’t worry.
What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a large refactoring or other big change, then that was work best done on a weekend because branching and merging didn’t work very well.
Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.
You can totally use that workflow with git.
This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results.
I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.
I certainly don’t think anything is a sure thing.
Congrats on the new role, sounds exciting - looking forward to seeing where it goes!
Thanks so much!
[flagged]
> 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.
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!
> I respect your opinion
Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.
Perhaps take a look at jj and give it a go. Maybe you’ll like it.
I know I did. The fact I can use it with git and it doesn’t interfere with any GitHub PR workflows means no-one needs to know I use it. I enjoy the jj model. Maybe you could too, and it’s not a crazy investment of time and energy. It’s an evening playing around with a code kata or something.
Then working with vcs becomes that little bit more enjoyable.
> 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
sounds like someone hasn't used jujutsu
> 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.
These are my thoughts exactly. Focus on building the best thing instead of telling everyone about the dreams you want to reach. Speak softly and carry a big stick as it were.
> 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.),
Is Steve even a developer for jj?
I have not contributed to jj directly basically at all yet: https://github.com/jj-vcs/jj/commits?author=steveklabnik
I am assuming that this new job will change that.
Found linus' alt
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.