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.
Just get the thing you need now, there's no promise the grass is getting any greener, nor that you're any better off waiting. Maybe the LLM won't learn for 6 months. Or 12 months. Or maybe the AI company will run out of money, or jack up their prices to where you're not using it anymore, or whatever.
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?
+ 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.
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.
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.
Makes sense. Developers I know have been wanting that.
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.
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
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
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)
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 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...
The core of their complaint is that if you use `jj edit` it's not obvious how to get a diff of what you did. The answer, of course, is that you can use `jj evolog -p`.
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."
Some of it is also what a "branch" means to different people can mean different things: https://jvns.ca/blog/2023/11/23/branches-intuition-reality/
But yeah, as others have said, not really possible in a general way, sadly.
- the working copy has a bookmark pointing to it
- there's some ancestor with a bookmark
- there's a single linear path between the two with no other bookmarks in between
Here's an example that represents a branch containing 3 commits named "bookmark-05ff" branched off of "bookmark-6825".
> jj log -r y:: -T builtin_log_redacted
@ urplyywu user-482a 2025-10-23 13:24:52 bookmark-05ff a334e2e1
│ (empty) (redacted)
○ lxxtnlxw user-482a 2025-10-23 13:24:46 git_head() 7e32fa6b
│ (empty) (redacted)
○ omktyuos user-482a 2025-10-23 13:24:13 7668b0bb
│ (empty) (redacted)
○ ykzktoux user-7b7f 2025-10-23 13:23:47 bookmark-6825 98bfcbde
│ (empty) (redacted)
~
> jj log -r 'latest(ancestors(@) & bookmarks(), 2) ~ @' -T builtin_log_redacted
○ ykzktoux user-7b7f 2025-10-23 13:23:47 bookmark-6825 98bfcbde
│ (empty) (redacted)
~
Also note this bakes in a lot of assumptions and is brittle. As many others have said, it’s not generalizable.
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/
You could probably attach metadata to commits indicating the branch name at time of creation, but there's probably a lot of weird edge cases to handle.
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.
https://github.com/jj-vcs/jj/blob/c70f9b5b3fff08a86fb11afc57...
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.
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.
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.
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.
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.
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 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?
--update-refs, --no-update-refs
Automatically force-update any branches that point to commits that
are being rebased. Any branches that are checked out in a worktree
are not updated in this way.
If the configuration variable rebase.updateRefs is set, then this
option can be used to override and disable this setting.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
jj does this for performance reasons. They don't want to perform a full checkout for every rebase action. This is simply something I disagree with
It's true that `jj fix` can be faster by not touching the working copy, but we also want a `jj run` command for the linter feature (https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.
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.)
The workflow still functions, it just requires me to manually update bookmarks.
I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of your time for no real reason. I wonder what the justification is.
Correct.
It makes sense to me because it leaves a linear history of git commits in response to comments on a PR which makes code review easier. We squash and rebase at the end.
> Just a waste of your time for no real reason. I wonder what the justification is.
We used to be on Gerrit, which I found better for code review as I could stack a bunch of minute changes together. I probably had 50-100% more productivity on Gerrit before my team made the switch.
Unfortunately, the industry standard is GitHub PRs. My team wasted a ton of time onboarding people to Gerrit and even after onboarding, less than 5% of people understood stacked changes enough to use them effectively.
Since force pushing/rebasing messes up GitHub PRs it was banned.
If you have suggestions for alternative code review workflows on GitHub I'm happy to hear them, but ideally they could be incremental.
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.
(The mention of the GitHub SVP being interested in stacked diffs sounds good in that regard. I'm also keeping an eye on Tangled and, now, on ERSC.)
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.
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.
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.
Not really? From someone's post here a year ago:
> The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id.
Anybody who's wrestled with reordering/rebasing git history or has done git archaology is able to understand this benefit.
From Pijul's site:
> Pijul is the first distributed version control system to be based on a sound mathematical theory of changes
After years of grudgingly tolerating using a deployed prototype for a VCS, yes, I want the mathematically sound alternative.
All that being said, I do wish you the best, because truly, I am tired of git and JJ does seems like an improvement.
Most of my wrestling is with merge conflicts and a consistent tree doesn't help with that.
Who upvotes this?
So the article is more like “Here’s why I started using Rust. If you thought I made a good choice then, well, I’m making a similar choice in case you want to join me.” Seems people find that compelling.
Just like Rust’s success was not inevitable, neither is jj’s. But I think it might work out.
You could also consider this a disclosure of sorts, I post a lot on this forum about jj (and Rust), and so knowing that I now have a financial incentive is important context to some people.
- Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
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.
If I may make a suggestion here: Allowing PRs to be stacked, i.e. allowing commits to be reviewed individually, like in Sapling, would be FANTASTIC.
EDIT: See also the link in this comment: https://news.ycombinator.com/item?id=45675335
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.
Demo: run `git cat-file -p HEAD` in any jj repository that you've made a change to.
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!
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).
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'm going back starting on monday, so I'm curious to try out jj.
In the past 10 years it's all been github and gitlab, and their code review tools are so painful, specifically w.r.t. tracking discussions across revisions. I never felt excited to try out jj because I was afraid it would that situation even worse.
I'll venture that jj is there to stay, however. If not at Google, then in general. It's just too much of a quantum leap. I think I've finally identified what about it sits so right with me: a change's identity is preserved through its revisions. In bare git, after a rebase or an amend, you get a wholly different commit that just happens to have a similar content.
Mind you, I'll also venture that jj will remain based on git as its storage backend, despite its stated goal otherwise. Git's internals are just too good at what they do to make it worthwhile to replace them.
Steve, if you come to NYC hit me up!
It has always annoyed me that there's not any clever way to handle binary changes with version control.
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.
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.
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’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers.
It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone after the call, and it’s clunky to use and to save.
… but technically the feature exists, so it’s harder to argue for better software thats fit for purpose, like miro or mural.
If the primary filetype you use is binary, you’ll start to feel the jank.
2. Artists can actually understand Perforce.
That's literally the antithesis of Git. If that's a requirement, then yeah - Git's the wrong thing.
It's like complaining that bicycles don't have motors like motorcycles. If it had a motor, it wouldn't be a bicycle.
Anyway, I dunno, man. If you want binary files to work, some form of per-file mutex is indeed a requirement. And for this to work well, without being a lot of hassle (and regarding that, see point 2, which I note has been accepted without comment - not that I expected anything else, the argument that Git is the artist-friendly choice would be a difficult one to make), any modification of the mutex's state has to involve a round trip to ensure the info is up to date. You can't rely on something local, that only gets updated sometimes, because then the info can be out of date! Worst case, N people find out too late that they've all been making changes simultaneously, and now N-1 of them will almost certainly lose work.
(You might be inclined to moan at people for not going through the full process, but: we have computers now! They can do the full process for us!)
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.
I mean that's just toxic.
Discussion: https://news.ycombinator.com/item?id=45083952
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.
I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.
An incomplete list of wins vs StGit includes:
- jj makes managing multiple branches fluid, whereas stg has limited tools for managing patches between stacks. 'stg pick' is largely all there is. It's a real dance to move a patch between stacks.
- jj has a much better system for naming changes. I'm super jealous of how jj solved this problem. StGit requires you to name the patches. I added the feature that allows StGit to refer to patches by relative or absolute index in addition to by name. jj's immutable change ids that can be referenced by unambiguous prefix is the correct answer to this problem.
- 'jj rebase' is so vastly superior to stg push/pop/sink/float for reordering changes that I don't even know where to start. It wasn't immediately obvious to me just how flexible, simple, and powerful 'jj rebase' is when I first started using jj, I have learned that it is in its own league relative to StGit's stack ordering story.
- Similarly 'jj squash' makes 'stg squash' look amateurish.
I could go on. If you're a StGit user, you owe it to yourself to give jj a proper try.
* I have a branch foo with a stack of patches which are the thing I'm working on, based on a master branch
* I have a separate stack of patches on a branch bar (let's say this is a feature that interacts with foo but it's not ready to upstream yet or maybe at all)
* I want to test and work on the combination of foo and bar and make changes that might need to be updates to some patch in foo, or to some patch in bar
At the moment I pick all the patches in foo onto bar in order to do the work and updates in this combined branch, squashing fixes and changes into appropriate patches. Then once I'm happy I go back to the foo branch, blow away the old patches and re-pick them off my combined branch.
This works but feels super clunky -- does jj do better here? That would be a real incentive to try it out.
For the rest, they don't sound like they're strong enough to beat "I've used stgit for 10 years and have a solid workflow with it".
And I just scanned the jj rebase docs and it looks awful, everything I moved to stgit to get away from. I do not want to think about managing a patch stack in terms of "move a bunch of revisions to a different parent". I like having a straightforward stack of patches that I can push, pop and reorder and list. Don't make me think about graphs of commits and multiple rebase suboptions and all that for something that I do all the time in my main workflow, please.
Combined with jj absorb, some people just work this way all the time, even.
> I like having a straightforward stack of patches that I can push, pop and reorder and list.
You can work this way too, what you'd want is `jj rebase` with -A, -B, and -r: r for the revision, and A and B for the before and after you want to move it too. This lets you reorder things however you want pretty straightforwardly. I tend to work in a stack of patches too, or at least, way more than I used to.
Anyway you should use the tools you like, it’s all good.
For example, I frequently use `jj up` to rebase the current branch on main. Likewise, `jj pop` rebases just the current commit (popping it from its current place). I even have a `jj ppop` - better name suggestions are welcome - which does this but for the parent commit.
I suspect that the once-off effort to write your own commands would take no longer than it would take to read the documentation if the commands already existed, but with the hopeful extra benefit of giving you a better understanding of how to use rebase for those once in six months weird requirements when they may arise.
But to be clear, I'm not suggesting you must or even should put in this effort if you have something that works for you. My reply is mostly so that anyone who comes across this discussion and sees Steve's mention of -A, -B, etc isn't scared off by them. Whilst they're always there for you, you can use the power it gives you but in the form of single function commands that don't require you to think.
---
For anyone wondering, the aliases I mentioned. These can be dropped in your jj config with `jj config edit --user`.
[aliases]
up = ["rebase", "--skip-emptied", "-d", "trunk()"]`
pop = ["rebase", "-r", "@", "-d", "trunk()"]
ppop = ["rebase", "-r", "@-", "-d", "trunk()"]Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation.
* Or we can completely change how we write code…
With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits.
Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.
Small commits are the same small commits in jj as in git, you just split instead of add -p.
You can also stage or unstage lines by selecting them first and press the relevan keys.
If you press ‘return’ on a hunk, it brings you directly the the line to edit.
actually, with jj's seamless rebases, it'd work exactly as you'd want it to (but maybe not how you'd expect if you're used to the git way) when aimed at a commit in the middle of a branch: pick lines which stay below, above or in the middle commit, which you can edit transparently.
Interactive rebasing is a breeze. Editing commits is very fast (reordering, dropping rewording, splitting,…). Same with dealing with merge conflicts (Emacs have various merge packages builtin).
The same speed Vim brings to editing, that’s nearly the same speed you get with magit for git.
Does not sound any easier or more intuitive than git.
It isn’t how git porcelain wants you to work, but it does make sense once you stop thinking in git. Working copy being a first class commit unlocks all the dag manipulation tools without stashing, having to resolve conflicts in middle of tricky operations, etc. ‘Easier’ is exactly the point, but it’s about workflows which are very inconvenient in git like rebasing stacked PRs.
Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.
It actually sounds like you're confusing jj with something else.
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 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 starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult ohshitgit.com because there's half a dozen different commands to know to undo everything.
Another is a simplified model whose pieces compose better with each other. There's no need for staging or stashes in jj. You essentially work in a HEAD commit all the time, and when it's ready, you commit what you want, make a new child commit and keep going. A stash is just some random commit. Anything you've learned about manipulating commits now applies to "stashes" with no extra effort.
No need for branch names. If you come from git, learning that "stashes" are just random little HEAD commits may make you groan and think you have to give each of those branches a name. jj doesn't care about that. I still give major branches a name, but since I don't have to name them in general, it's easier to create lots of little branch "experiments". Branch names were never really a substitute for commit messages, anyway.
More rebase-friendly IDs. Git penalizes the use of SHAs when rebasing, whereas in jj, change IDs are stable after rebasing, making them actually usable. This makes rebasing easier and safer.
First-class conflicts. Git forces you to stop the world and deal with conflicts immediately, or back out entirely. This isn't really required, and jj has no opinion. It marks conflicted changes, and waits for you to get around to fixing them. This is great when your boss interrupts you for something high-priority. It also automatically rebases all downstream changes after you've fixed it, which usually clears their conflicts too.
Megamerge workflow. This is possibly doable in git, but I don't know how easy the workflow is. But in jj, creating a work commit that has multiple branches as parents is trivial, as is pushing work down into individual parent branches. This makes integration easier, as you can easily see how your upcoming changes interact with your colleagues' upcoming changes.
Jujutsu's not a revolutionary VCS change (like Pijul's theories of commutative patches), but it's generally way more pleasant to use, with better DX, than git. I gave up git forever after two weeks of jj.
The typical workflow would be:
1. `jj log ...`
Locate the change ID of whatever change needs altering.
2. `jj new $SOME_CHANGE_ID`
This creates a new, empty change whose parent is the change you want to edit
3. Make your changes, pass the tests, etc.
4. `jj squash`
All your changes get squashed into $SOME_CHANGE_ID
5. jj then automatically rebases everything downstream of $SOME_CHANGE_ID for you.
All jj change IDs remain the same (though the underlying git commit SHAs are now different.)
If there are any new conflicts introduced in the downstream changes, they'll get flagged. You'd then typically run `jj new $FIRST_CONFLICT_ID`, and repeat the whole process.
---
It's also possible to run `jj edit $SOME_CHANGE_ID`, to work directly on that change, but because of the automatic rebasing, it's preferable to work on a child commit and only squash when ready. (In case you need to do other things with downstream changes before you've finished making your updates.)
---
Does that answer your question?
Recently jj started including the change id in a header in the git object, so the receiving side can choose to respect/expose them as appropriate. An issue with this is that some git commands don’t guarantee the preservation of headers, so it’s possible to accidentally lose them; git rebase being a prime example.
Generally, when a new change ID is needed, jj generates a random number. The individual commits under each change still use hashed SHAs.
> when I can modify the whole commit
You can't actually modify any commits. A mutable change can be thought of as a subset of immutable git commits with a pointer to the most recent commit.
When you alter a file and jj snapshots, it adds immutable commits to the DAG end, and updates the pointer.
---
There's some exceptions, like when importing from git, it will generate new change IDs based on a transform of the git SHAs.
---
Side note: as much as I like jj, I admit the change/commit terminology is confusing as hell.
What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this, you don't need to use it, these features are purely additive.
In fact, the most popular jj workflow is closer to the git add -p workflow than it is git commit -a. I’d argue more jj developers work this way than git developers do in git, even.
> backlog of temporary commits
So a list somewhere else, which commits are considered temporary. It's a todo list for commits. Does JJ have that?
> We've unified two things into one thing.
A stash in Git is also just two commits. So no you just removed a feature on top of that. That feature might not be to your taste, or even outright confusing, but you did remove it.
The git features of stashing/staging are removed, but they're superfluous given how jj works. You don't need or want them, and keeping them around would only give people two ways to do the same things.
> give people two ways to do the same
This is where I am disagreeing. I do want them.
for, while and goto achieve the same and are the same thing under the hood, yet they convey different semantic and you choose between them for different tasks, because they are more suited for different things.
stashes and commits achieve the same and are the same thing under the hood (both are commits), yet they convey different semantic and I choose between them for different tasks, because they are more suited for different things.
All in software is about different abstractions, that all fundamentally do the same thing.
> but it's all easier in jj
You can literally use commits instead of stashes in Git and guess what: it's the same as treating any other commit. Here JJ and Git are the same. You can also do stashes in Git, when you want temporary commits that are put into a "todo" list.
I think for me, the unification of concepts, and simplification of DX, wins out. I like being able to use the same set of commands for all three. I didn't miss staging or stashes at all when I switched.
There's no loss of speed, functionality or power, and as a bonus, instead of maintaining 3 separate concepts and commands, they're now handled by 1.
It's honestly much simpler. A git stash is effectively a commit already, but stored weirdly, doesn't show up in the logs by default, and with its own ad hoc commands.
As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing.
I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks.
Sure, jj might solve some issues, but once it gets serious traction, all the tooling that works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere).
Given all the downstream effects, I do not think introducing another VCS is a net positive.
Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).
I highly doubt that new tools will be 10x better than git. Maybe 20%?
That's just one aspect of the whole thing, and of course if you're a git rebase wizard (or have tools that make you that) then this won't seem relevant. But I think for a lot of people this might be a salient point.
Will a product that is 10x better see rapid adoption if people who have not used it still choose to criticize it in the abstract?
I think this is JJ's biggest advantage. Whether you use it is independent of whether anybody on your team uses it.
I do agree that you can't really use jj without also knowing "a fair amount" about git, but notably you never need to use the git cli to be an effective contributor to a github project, which is basically the same as `git-svn` was back before git got popular.
More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere).
All the tooling that works with e.g. repo analysis will need to start supporting git and jj
However, my point is that having two ways of doing this within a team is already confusing. What if one person writes a "this is how we work" document on the wiki and mentions some git, and the next person rewrites it to jj? It's extra things to think about. It's like supporting developers from a team with both Windows and Linux (Debian, Arch, Ubuntu, etc). Teams do it, and it's all possible, but it was nice that at least everyone used git.
The next generation of VCS should be atomic, with a proper database tracking atoms, and "plans" to construct repo states from atoms. A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans), you could construct relationships from plan edit distances and timestamps without forcing developers to screw with a graph. This would also allow macros to run on plans and transform atoms, enable cleaner "diffs" and make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch.
The downside of an atomic design like this is you have to parse everything that goes into VCS to get benefits, but you can fallback to line based parsing for text files, and you can store pointers to blobs that aren't parseable. I think the tradeoff in terms of DX and features is worth it but getting people off git is going to be an epic lift.
You may not be "forcing" developers to "screw with a graph" (what?) but you are forcing them to screw with macros (we're adding a built-in scripting layer to the VCS?) and these unfamiliar new concepts called atoms and plans.
> A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans)
And it would introduce zero new confusing issues of its own?
> This would also [...] make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch.
This is a weird use case. Version control systems aren't typically used for storing and swapping around bits of functionality as a first-class, ongoing concern.
Not to mention you still need to figure out how atoms get stitched together. How do you do it without diff-based patches? No superior solution exists, AFAIK.
tl;dr use workspaces if you're using agents.I'm sure there would be new issues, but I think they'd be at the management/ops level rather than the individual dev level, which is a win since you can concentrate specialization and let your average devs have better DX.
Is it a weird use case? Imagine you refactor some code, but then you realize that a function was being called in a slightly incorrect way after a change (prior to the refactor so the revert isn't trivial) and you have to go back and revert that change, let's say over 100 files to be fun, and let's say that the code isn't perfectly identical. With git you probably have to do surgery to create a patch, with an atomic system you can easily macro this change, or you could even expose a UI to browse different revisions of a piece of code cleanly (which would blow up with git).
Is this an oblique way of saying that Git should not be replaced?
Edit: Ah in fact, just like your personal account already is, so you know how straightforward it is :)
The git CLI might suck, but SM just doesn't. Looking forward to jj GUIs taking off. Or even better: jj getting integrated into SM.
I’m going to be slowly adopting it for work.
joshstrange•3mo ago
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.
steveklabnik•3mo ago
I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
simultsop•3mo ago
sunshowers•3mo ago